Re: pthread_mutex is not released when process closes

Chris Friesen wrote:
Dave Butenhof wrote:
Chris Friesen wrote:

If the memory that was trashed is not in the data protected by a particular mutex (and possibly not even accessable), why would the next entity to aquire that mutex care about it?

Because the application is now in an unknown and unreliable state, maybe? Even if a previous corruption didn't happen to affect THIS shared data, continuing execution as if nothing happened might well do it later.

I think I see what you're getting at. The real issue is that the application that went nuts could theoretically have trampled data not protected by any of the mutexes held at the time it went nuts. In a multithreaded environment this could be particularly nasty.

Even so, there are cases where "robust" mutexes could still be useful. I have an app where two separate processes both access a single chunk of shared memory. They currently use file locking to synchronize, but a process-shared mutex would work as well. If I were to include a CRC of the data in the shared memory area, then if one of them dies while holding the mutex, the other could easily verify whether the data is self-consistent simply by verifying the CRC.

Yes, there are. But only for this sort of scenerio, where the shared area of memory is small, controlled, and "provably correct[able]"... or in a monolithic app where literally ALL memory can be analyzed and repaired. Both are very special cases, and the original phase of POSIX threading was, deliberately, narrowly focused on general purpose primitives. (And enough of THEM were sufficiently contentious without dealing with even more specialized cases like this.)

MOST code cannot "prove" that all possible shared memory with the dead process is correct. And certainly not with a fully shared address space inhabited by completely independent shared libraries.

If the app that died corrupted other memory it really doesn't matter to the second app, because the only chunk it cares about (and in this case the only area it can actually see) would be covered by the mutex.

Sure... as long as there's NO other possible "leakage" beyond a region of memory you know and can reliably repair. Again... it DOES happen, but it's definitely not a common case.
.

Relevant Pages

  • Re: Mutex Problem
    ... the slave can) then yes, you can use CreateMutex in the master and OpenMutex ... Note, however, that if the slave app starts earlier, then it ... would not get the mutex. ... shared memory, and for this reason each of these applications tries to create ...
    (microsoft.public.platformsdk.security)
  • Re: How to implement synchronous rpc between 2 processes on the same machine.
    ... DOORS(it is a properietry and quite efficient IPC by SUN) ... there to just review this design and provide your much needed inputs. ... Multi-process shared memory impls need to think about misbehaving process.. ... non-blocking timed mutex in there. ...
    (comp.programming.threads)
  • Re: event driven paradigm
    ... This last paragraph sounds like you are confusing threads and processes. ... If you have a multi-process model, then the sockets or pipes with ... In contrast to your assumption of my "shared memory" ... creating a mutex per thread and signal the mutex to wake up each thread ...
    (comp.programming.threads)
  • Re: PTHREAD_PROCESS_SHARED on GNU/Linux
    ... a stock Linux kernel won't release the lock on behalf of the ... mutex, so you'd probably have to stop everything and re-initialize the ... shared memory if any process dies unexpectedly. ... If a process dies unexpectedly while holding a mutex, ...
    (comp.programming.threads)
  • Re: Shared-memory between threads and synchronization
    ... In my project i am having different data structures ... process and shared memory should be accessed between different ... co-ordinate activities just through a mutex. ... If the scheduled thread doesnt need the mutexed resource, ...
    (comp.os.linux.development.system)