PTHREAD_MUTEX_ROBUST for tdb?
rusty at rustcorp.com.au
Tue May 17 18:47:15 MDT 2011
On Tue, 17 May 2011 14:17:15 +0200, Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
> 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
> 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.
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.
More information about the samba-technical