PTHREAD_MUTEX_ROBUST for tdb?

[Rusty Russell]

On Tue, 17 May 2011 14:17:15 +0200, Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
> Hi!
> 
> For years I have had a low-prio thread sitting in my mind
> about getting rid of the fcntl calls for tdb access. A
> couple of years ago I've discovered PTHREAD_PROCESS_SHARED
> which make pthread mutexes cross-process. They are not
> robust though, if a lock holder dies the mutex won't be
> unlocked automatically. Now I was pointed out that in SUSV4
> we have
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html
> 
> which gives seems to do exactly what we want. I've written a
> tiny non-error checking test program. In one window, run
> 
> ./mutex /tmp/mutexfile init
> 
> and in another windows run
> 
> ./mutex /tmp/mutexfile
> 
> and kill -9 the first instance. The second one will be woken
> up with EOWNERDEAD.
> 
> We get an additional benefit over fcntl locks: We can tell
> whether a lock holder dies hard while holding a lock, so we
> at least know when the tdb is potentially hosed.
> 
> To me this looks VERY promising. The first caller does not
> do any syscalls on my Ubuntu Linux box to lock the mutex,
> the second caller sits in a futex call.
> 
> Comments?

As I just replied on a private variant of this:

Yes.  It's not very portable, but it is in recent Linux and glibcs.

As far as I can tell, embedding a pthread mutex into a memory mapped
file is going to be a bit of a nightmare :(  Its size is not necessarily
stable over glibc changes, for example.

We could use the robust futex support and open-code it for Linux
ourselves, at least for x86 which we care about.  This would be a fun
project, but a non-trivial one.

Cheers,
Rusty.