I've always imagined that, just like memory, it is the OS' responsibility to clean up after a process once it ends. Unfortunately, I'm having trouble finding much evidence of this, so I can't really guarantee what happens.
My main question is, what would happen if a process is locking a mutex, and it were to exit abruptly with little or no cleanup (i.e., calling abort in C, or terminate in C++)?
Is there any guarantee that the OS will unlock the mutex, or is it just implied that most reputable systems would (similar to unreleased memory)?
If there is no guarantee, could this actually create a deadlock between a process still running, and the lock held by the dead process?
If a deadlock can be created this way, can this be replicated between threads of a process, rather than through a shared mutex between separate processes?
If the mutex object was owned be the exiting process (either by means of create or open) its handle will be closed upon termination of the process.
The other processes wait operation will return on such ocasion:
For Windows, i.e. WaitForSingleObject(...)
returns WAIT_ABANDONED
which means:
The specified object is a mutex object that was not released by the thread that owned the mutex object before the owning thread terminated. Ownership of the mutex object is granted to the calling thread and the mutex state is set to nonsignaled. If the mutex was protecting persistent state information, you should check it for consistency.
For Linux, i.e. pthread_mutex_lock(...)
returns EINVAL
which means:
The value specified by mutex does not refer to an initialised mutex object.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With