El 25/08/2011 20:53, David Byron escribió:
Instead of using a persistent integer on windows, how about CreateMutex Then if the mutex holder dies, the other side learns about it because WaitForSingleObject returns WAIT_ABANDONED. But then it's not so important to learn that the other side is dead...just that we've got the mutex and it's OK to proceed.
The key problem is object lifetime. In windows, when last attached process dies/closes the handle, the interprocess mechanism is automatically destroyed. In Unix, it's more like a file and an explicit unlink must be done. That's the real problem of portable semantics between windows and unix.
My understanding is that a process waiting on a posix interprocess_mutex wakes up (having taken ownership) if the owner process dies. Is that right? Adding an implementation for windows that behaves that way feels like a big bonus -- way better than hanging.
No. There is an option, robust mutexes, not implemented by all systems, that establishes a protocol for handling abandoned mutexes: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_...
The queue is removed (in windows, the name of the queue is changed so that no other connection succeeds and marked to be erased when the last handle is closed,
That's useful information, but what I'm also curious about is whether the process waiting for the mutex wakes up or not. Using the emulated interprocess_mutex, I'm not sure. Because the waiting process still likely has a handle, I guess it hangs forever, yes?
It will hang, yes, just like in a posix system without robust mutex support. Adding robust mutex support is in my to-do list, exploring some emulation for windows too, but I guess that would require a huge amount, because I don't know any portable runtime that has achieved this. Best, Ion