Sign in to follow this  
blueshogun96

Using named POSIX mutexes?

Recommended Posts

Okay, I have a question about using POSIX mutexes.  I've searched all over the net, but I can't find any examples on how to create a named POSIX mutex.  Can this be done?  I've searched google for quite some time, and no concrete answers appear.

 

Also, assuming a named POSIX mutex can be created, can I create the same named mutex twice?  I'm asking because the primary purpose I'm asking is because I'm attempting to write some code that detects multiple instances of my app running on the same machine for Linux and MacOSX.  The steps (in theory):

 

- Attempt to create a mutex with a specific name that matches the app's ID.

- If it already exists, then this app is already running.

- If not, save this mutex until the app exits, then destroy it so the app can be relaunched.

 

This is how I handle this problem using Windows, so I assumed you could do the same thing using MacOSX and Linux.  If not, then I'll use a slightly messier solution, a file lock (yuk!).  Any ideas?  Thanks.

 

Shogun.

Share this post


Link to post
Share on other sites

I'm not sure if pthread defines system-wide named mutexes, but the POSIX standard defines named semaphores, and a mutex is just a special kind of semaphore (that only takes values 1 and 0 and that is initialized to 1) so that should be good enough if not as handy.

 

Look at the sem_open function for how to use it. You might also want to read that SO question: http://stackoverflow.com/questions/16400820/c-how-to-use-posix-semaphores-on-forked-processes

I tried the POSIX semaphore idea, and that worked like a charm.  So much nicer than file locking...

 

Shogun.

Share this post


Link to post
Share on other sites


I'm asking because the primary purpose I'm asking is because I'm attempting to write some code that detects multiple instances of my app running on the same machine for Linux and MacOSX.  The steps (in theory):
 
- Attempt to create a mutex with a specific name that matches the app's ID.
- If it already exists, then this app is already running.
- If not, save this mutex until the app exits, then destroy it so the app can be relaunched.

 

I realize you may have already found an answer to HOW, but I'm wondering about the reason WHY?

 

 

Is there some reason you must prevent multiple instances of your app at once?   I know often you prefer your game to be run one way, but is there a reason you must absolutely forbid it from being run another way?

 

 

As an example, on several titles I found it useful to launch several instances of a game, perhaps 2 or 3 or 4, all on a single machine.  I'll have them connect to a game server (also running on the same machine) and hook up one or two debuggers as needed.  Yes, the performance degrades into something terrible, but for debugging purposes it is far easier than finding four open machines to use, or configuring my machine to run four virtual machines and running the game inside each. 

 

As another example, sometimes games appear to close quickly by destroying and hiding windows but continue to run in the background cleaning up resources for quite some time. Or they crash and it takes the operating system an extended time to clean everything up.  In that case I may want to launch another instance of the game immediately, and if some stupid shared object is still hanging around it can take quite some time before I am allowed to start my next instance.

 

 

The point is, it seems like you are trying to force your decision that your game is really a singleton onto the user.  For whatever reason, you have decided that even if the user wants more than one the user is wrong, and the user's decision shall be overruled.  Usually that is the wrong decision.

Share this post


Link to post
Share on other sites

 


I'm asking because the primary purpose I'm asking is because I'm attempting to write some code that detects multiple instances of my app running on the same machine for Linux and MacOSX.  The steps (in theory):
 
- Attempt to create a mutex with a specific name that matches the app's ID.
- If it already exists, then this app is already running.
- If not, save this mutex until the app exits, then destroy it so the app can be relaunched.

 

I realize you may have already found an answer to HOW, but I'm wondering about the reason WHY?

 

 

Is there some reason you must prevent multiple instances of your app at once?   I know often you prefer your game to be run one way, but is there a reason you must absolutely forbid it from being run another way?

 

 

As an example, on several titles I found it useful to launch several instances of a game, perhaps 2 or 3 or 4, all on a single machine.  I'll have them connect to a game server (also running on the same machine) and hook up one or two debuggers as needed.  Yes, the performance degrades into something terrible, but for debugging purposes it is far easier than finding four open machines to use, or configuring my machine to run four virtual machines and running the game inside each. 

 

As another example, sometimes games appear to close quickly by destroying and hiding windows but continue to run in the background cleaning up resources for quite some time. Or they crash and it takes the operating system an extended time to clean everything up.  In that case I may want to launch another instance of the game immediately, and if some stupid shared object is still hanging around it can take quite some time before I am allowed to start my next instance.

 

 

The point is, it seems like you are trying to force your decision that your game is really a singleton onto the user.  For whatever reason, you have decided that even if the user wants more than one the user is wrong, and the user's decision shall be overruled.  Usually that is the wrong decision.

 

Good points (and many of which I didn't think of).  Although I have multiple machines handy to test networked games, I'll have to try that idea.

 

This is actually some functionality I'm adding to my engine (not necessarily to a specific game), where the programmer can choose what he wants to do when there's multiple instances existing.  The exiting/shutdown case you stated is a good reason not to force it, but sometimes when it takes a minute or two for your game to load/start, the user might get impatient and just start clicking away thinking "why won't you start?", and then end up with multiple instances of the game running as a result.  This has happened to me before, and it's been a pain to close out multiple windows of a AAA resource hog, especially if I'm in fullscreen.  To me, it's undesirable from an end user standpoint.

 

A better solution would be to display a dialog stating that there is another instance of the game running, and allow the user to confirm that he wants two or more instances running.  And as a bonus, include a check box that says "Do not display this message in the future".  How does that sound?

 

Shogun.

Share this post


Link to post
Share on other sites

 


sometimes when it takes a minute or two for your game to load/start, the user might get impatient and just start clicking away thinking "why won't you start?",
Show a splash screen first that says something along of "Loading the game, please wait.", then init the game.

 

Good idea, but in my experience, a splash screen isn't guaranteed to show up immediately.  Example: Unreal Tournament 2004.  Sometimes it would take like 30 seconds to a whole minute for it to show up back in the day.  So I personally never rely on the speed of a user's host machine to deliver a message within a reasonable amount of time.

 

Shogun.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this