[cgl_discussion] Details on the implementation of Robust Mutexes (as Sun's POSIX e xtension)

Perez-Gonzalez, Inaky inaky.perez-gonzalez at intel.com
Thu Mar 13 11:15:26 PST 2003

Hi Pradeep, All

We were in the process of discussing some issues with the Sun Robust Mutexes
extension - well, I am the one with the issues. I wanted to run it through
you (as you were the first to bring up the requirement) and the list to get
your opinion/s.

Sun states that when a mutex waiter gets a mutex whose owner died, it gets
it with error code EOWNERDEAD. That waiter has to make the state of the data
structures protected by the mutex consistent and then make the mutex
consistent with pthread_mutex_consistent_np(). Then the mutex is back to
normal operation.

However, on the event of that waiter not being able to fix the state, it
unlocks it. Now, the next waiter (if any) or next task trying to acquire the
mutex will receive an ENOTRECOVERABLE, and the only way to get the mutex to
be consistent again will be by reinitializing this.

So, here is my issue: I see this kind of limiting, not to say short-sighted.
I could be missing something, but I plainly don't see it right.

This is just a two state inconsistency system, where only one waiter is
given the ability to fix it. What if you have different applications
coordinating through the mutex, being only one of them able to fix it? I
would expect (and to me it makes more sense, not to talk about it being
easier to implement) that the mutex stays in EOWNERDEAD until someone issues
a pthread_mutex_consistent_np() (consistent data) or pthread_mutex_init()
(inconsistent data). 

This way if an owner dies and I have three waiters waiting for it, the mutex
is going to be water-fallen through the three waiters until one can fix it.
If none were able to fix it, it will stay like that until some other locker
acquires it and fixes it. If nobody can fix it, the application is
definitely broken.

So, this is my issue. As you guys deal everyday with this feature, that's
why I wanted to ask what you think about this.

Thanks :)

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

More information about the cgl_discussion mailing list