How do you handle Mutex?

[Gilzu]

AFAIK, Mutex is a good tool to limit instances of your game. I simply want to avoid a case where a user accidently runs more than one copy of my game at once.

So i used a Mutex (tried both window's and SDL_mutex) and there's seems to be some nasty, annoying bug with SDL / SDL_mixer that makes your game crash. Took me two days just to figure out the reason for it.

Searching for a solution for the bug didn't help much - there's seems to be some documentation about this bug, but no real bypass / solution or even a hint for one.

I have considered using the old method of creating a file and disallowing any other instance to continue while this file is around - but its disadvantage that once your game crashes, you need to manually remove this file.

so... does anyone have experience with SDL & SDL_mixer while using Mutex? or maybe a better method?

[ggambett]

Mutex ("MUTual EXclusion") objects are a synchronization primitive used to prevent simultaneous access to a resource or a section of code. Theoretically you can do what you want with a mutex, but only if you use a system-wide mutex - otherwise, both copies of your game will have a different mutex. This is probably unrelated to your SDL_Mixer crash (I use SDL_Mixer and SDL_Mutex without problems) but if it didn't crash, it probably wouldn't work either.

In Windows you can manually create a global mutex (using the Windows API, not SDL). A trick I'm using but I'm not entirely happy with is registering a window class with a game-specific name (instead of SDL_App), and checking for that instance on startup. If it's already registered, the game is running.

[Savant]

For my own education, how is this thread cool but this one isn't:

http://forums.indiegamer.com/showthread.php?t=7351

I'm just trying to get a handle on the moderating process.

[mahlzeit]

Another trick you can use is to open a server socket on a predefined port number and listen for incoming messages. If you can't open the socket that means another instance of your app is already runnings, so connect to that port and send it your command line parameters, then exit. Works on all platforms. Disadvantage is that you need to use a port number that no one else is using.

[princec]

For my own education, how is this thread cool but this one isn't:

http://forums.indiegamer.com/showthread.php?t=7351

I'm just trying to get a handle on the moderating process.
I think because this question is about a specific technical trick whereas the other question was extremely vague and the sort of thing that has many answers and indicative of someone a bit clueless who might do well to ask in some more "my first program" forum like Gamedev.

Cas :)

[BarrySlisk]

For my own education, how is this thread cool but this one isn't:

http://forums.indiegamer.com/showthread.php?t=7351

I'm just trying to get a handle on the moderating process.

I don't get it either. I think the description for the forum should be more specific if technical questions are not allowed in the technical forum :) I can understand why some people get confused and post technical questions.

Gilzu:
If only you used C#, then I would have some code which loops through the running processes on the machine and if the process with the same name as my own program is running it would just quit. I'm sure the same thing can be done in C++ or whatever you are using. The open socket method screams HACK!

[Donavon Keithley]

What was the problem with CreateMutex?

This is what I use at the head of my WinMain:

CreateMutex(NULL, TRUE, _T("MyAppSingletonMutex"));
if (GetLastError() == ERROR_ALREADY_EXISTS)
return 0;

Pretty simple, and it hasn't given me any problems yet.

(Like the docs say, a malicious app could conceivably generate the mutex and block you from running, but I'm not paranoid enough to care.)

[ggambett]

For my own education, how is this thread cool but this one isn't: [...] I'm just trying to get a handle on the moderating process.
Sure, I'll try to explain it very slowly. This thread asks whether a relatively complex sinchronization primitive is the best way to enforce having a single instance of a game. This thread is also by Gilzu, an old timer who has contributed a lot to the forums over the years.

The other thread is by a newcomer (nothing wrong with that though) who started three very newbie-level threads - "Are indie games profitable?", asking "are there any famous and successful indie game developers known?" which means he didn't do any kind of search in the forum or basic research or else he would have heard of a certain PopCap. Lazy, but I'm cool with that. Second thread is a very basic question about paths - which has also been discussed at length previously (see Leper's posts). Lazy and redundant, but I'm cool with that too. The third is even more basic and clearly not suitable for this forum, so I politely explained why, pointed him to better resources, and locked the thread.

If you need further education or have any more questions, I'll be happy to answer them via PM.

[Savant]

Sure, I'll try to explain it very slowly.
No need to get snarky. I wasn't the only one confused.

OK, so it's evaluated on a case by case basis adjusted by how interested you are personally in talking about the topic at hand.

I understand. Thanks!

[Gilzu]

What was the problem with CreateMutex?

This is what I use at the head of my WinMain:

CreateMutex(NULL, TRUE, _T("MyAppSingletonMutex"));
if (GetLastError() == ERROR_ALREADY_EXISTS)
return 0;

Pretty simple, and it hasn't given me any problems yet.

(Like the docs say, a malicious app could conceivably generate the mutex and block you from running, but I'm not paranoid enough to care.)

This exact code causes the SDL / SDL_mixer Bug.
As I mentioned in my first post, I have tried this method and SDL_mutex method, and still this annoying bug occurs :(

[mahlzeit]

The open socket method screams HACK!
Not really. Using sockets is a very common way of doing interprocess communication. It may be overkill if you can get away with using a mutex, but if you're going to be passing around commandline parameters and whatnot, you'll have to use some form of IPC anyway. Also, not all programming languages can create system-wide mutexes. ;)

[Fabio]

The best way to do interprocess communication in Win32 is IMHO a shared DLL.

[Applewood]

FindWindow()

If you find your window, quit.

Or did I misunderstand - there's a lot of technical stuff above but if you wanna make sure only one version of your app is running, just look for it when you run :)

[MikeVitt]

This is probably obvious, but you can also then take that window handle and force the game to the foreground if minimized or behind another window like Explorer. Otherwise, the user might think there is an error when nothing happens.

[Applewood]

I forgot about this - good advice.

My engine used to do this for me automatically, but I disabled it a while back when I actually wanted to run 4 copies at once to test some networking code. Best to put it on a switch I think.

[JasonD]

Sure, I'll try to explain it very slowly.
Ouch.

...This thread is also by Gilzu, an old timer who has contributed a lot to the forums over the years.

The other thread is by a newcomer (nothing wrong with that though)...
I find it interesting to mention a point but immediately take it back with "but that doesn't matter". The fact that you state it shows it does matter. Taking it back shows you know, logically, it shouldn't matter.

OK, so it's evaluated on a case by case basis adjusted by how interested you are personally in talking about the topic at hand.
...and, apparently, it also matters who is asking the question. I am at a loss for words at this... especially after I just finished commending everyone for allowing the Pirate Software thread (http://forums.indiegamer.com/showthread.php?t=7402) to continue.

[dbehnke]

At the top of WinMain:

{
HWND hWnd = FindWindow( szClassName, NULL );
if ( IsWindow( hWnd ) )
{
HWND hWndPopup = GetLastActivePopup( hWnd );
if ( IsWindow( hWndPopup ) )
hWnd = hWndPopup;

SetForegroundWindow( hWnd );

if ( IsIconic( hWnd ) )
ShowWindow( hWnd, SW_RESTORE );

return 0;
}
}

Use a GUID (guidgen.exe) to *reasonably* (not totally) ensure your classname is unique.

[Fabio]

Use a GUID (guidgen.exe) to *reasonably* (not totally) ensure your classname is unique.
Microsoft has the merit of having introduced non-determinism in the computer world. :rolleyes: