"Robert O'Callahan" roc+@cs.cmu.edu writes:
Of course it has to be 100% reliable, but since you're dealing with failing processes it's not 100% clear what 100% reliability is. Anyway, I think 100% reliability is possible for any plausible definition.
For a mutex the basic definition is obviously that you can never have two threads holding the mutex at the same time, and that when it is released some other thread has a chance at grabbing it. This has to be true no matter what the process does, including corrupting memory or crashing. You also need to make sure nothing a process does should be able to crash/hang the wineserver or another process (except if they fight over the same mutex of course), and then there is the small matter of respecting the Win32 semantics...
Actually it is the last constraint that is the main problem. You can certainly provide some kind of mutexes using shared memory; but we don't need just 'some kind', we need Win32 mutexes. This means a mutex is identified by a handle that can be manipulated by CloseHandle or DuplicateHandle; it means you need to detect and handle abandoned mutexes; it means you must support WaitForMultipleObjects, including the 'all' case where you cannot grab the mutex unless all objects are signaled; all things that I didn't see in your implementation ;-)