CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7
  1. #1
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Does this excluding other instances method require synchronization?

    Hi everyone. I'm using the following method from within InitInstance() for the process to make sure that only one instance of the program is running at a time (for a single logon session):
    Code:
    HANDLE hSingleInstanceObj = ::CreateEvent(NULL, FALSE, FALSE, _T("Unique_process_name"));
    if(hSingleInstanceObj)
    {
    	//Did it already exist?
    	if(::GetLastError() == ERROR_ALREADY_EXISTS)
    	{
    		CloseHandle(hSingleInstanceObj);
    
    		//Exit this instance since another one is already running
    		return FALSE;
    	}
    }
    
    
    //Do main processing here
    ...
    
    
    //When the app exits
    CloseHandle(hSingleInstanceObj);
    hSingleInstanceObj = NULL;
    Now I'm wondering, does the method above guarantee that there'll be no second instance of this process running, or do I need additional interprocess synchronization for the CreateEvent() call?

  2. #2
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: Does this excluding other instances method require synchronization?

    You have have to use Mutex, not Event.
    Have a look at Avoiding Multiple Instances of an Application.
    Victor Nijegorodov

  3. #3
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: Does this excluding other instances method require synchronization?

    Internally the OS will serialize the calls to CreateMutex so you don't have to worry about the OS handing out duplicates.

  4. #4
    Join Date
    Nov 2007
    Posts
    35

    Re: Does this excluding other instances method require synchronization?

    For best results use a Guid string constant generated by a tool and pasted in for the name.
    They are legal for kernel object names.

    "{C116AAA6-F7F0-48B7-B52D-F6A7F605B678}"

    Don't use a function call that generates a Guid string since it will be different on every call and the test for a previous instance will fail. If you want to transfer the command line a few pages of Memory Mapped File using the paging file as backing works fine. You need to set up some method to test if there's valid data in the shared memory. Alternatively, to do it "automatically" you can create a message only window in the Main Instance using a Guid string for class name. In the second instance use WM_COPYDATA and SendMessage to send the command line over.

    If you use the Memory Mapped File method, then you can use the Mutex you already created to serialize access to the shared memory. The 2nd instance gets the mutex, writes command line stuff into the shared memory, surrenders the mutex and dies. The Main instance periodically tests for some flag in the shared memory that fresh data has been written in and copies it out while it has the mutex etc..

    Various ways to skin the cat. If you want to allow 2nd copies of the program under certain circumstances then you can use the message only window alone as the test for if an instance is already running. If the window with class name Guidname exists, you're not the main instance etc..
    Last edited by MilesAhead; November 8th, 2010 at 06:48 PM.

  5. #5
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Does this excluding other instances method require synchronization?

    >> You have have to use Mutex, not Event.
    Events will work as well. Both are named kernel objects.

    >> or do I need additional interprocess synchronization
    No, you don't. What you have is fine.

    http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

    gg

  6. #6
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: Does this excluding other instances method require synchronization?

    Thank you, guys. That's what I wanted to hear.

    As for using mutex vs. event, I agree, both should be kernel named objects and it doesn't matter which one is used in this sense.

    As for MilesAhead's suggestion, thanks, but I truly don't want to go too hard on it, especially with a memory mapping and sending window messages. Plus, however you look at it some name has to be statically linked and thus that negates the point of randomizing other names. Might be only my opinion though but I tried it out on one other thread and didn't succeed...

  7. #7
    Join Date
    Nov 2007
    Posts
    35

    Re: Does this excluding other instances method require synchronization?

    Quote Originally Posted by ahmd View Post
    Thank you, guys. That's what I wanted to hear.

    As for using mutex vs. event, I agree, both should be kernel named objects and it doesn't matter which one is used in this sense.

    As for MilesAhead's suggestion, thanks, but I truly don't want to go too hard on it, especially with a memory mapping and sending window messages. Plus, however you look at it some name has to be statically linked and thus that negates the point of randomizing other names. Might be only my opinion though but I tried it out on one other thread and didn't succeed...
    So your unique name is going to be "unique_name" ?
    I don't understand what you're talking about with randomizing names.

    If you are going to limit your app to a single instance then 99% of the time you need to handle command line param transfer since some user is going to launch another copy with a command line either through explorer shell extension or file association. Unless it's an unusual thing like some network service or something.

    If all you need is auto kill of instances then there are lots of techniques you can use without semaphores.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured