[Samba] Re: TDB locking overhead and performance...

[Daniel J Blueman]

On 22/04/06, David Collier-Brown <davec-b at rogers.com> wrote:
>    Linux indeed hs some fancy locks for this, which were tested
> with TDBs (see
> http://scholar.google.com/url?sa=U&q=http://www.realitydiluted.com/nptl-uclibc/docs/futex.pdf)
> but there is no discussion of what happens when we lose a
> process which is holding a mmap'd lock.  That was explicitly
> not addressed in the paper, from the Ottawa Linux Symposium.
> This may have been addressed by now, but I don't see any
> references to it.
>
>    Fcntl locks explicitly release if the locking process had
> died, so deadlock isn't a big issue.  For that reason they're
> preferred, even though they're far slower than spinlocks
> on Solaris (that's a Solaris bug, by the way).
>
> --dave

I was looking at futexes, but I found that current glibc packages
don't seem to provide a user-space header file (glibc seems to use
futexes internally). On top of this, we still need atomic operations,
which glibc doesn't provide to user-space.

glibc's pthreads use futexes (see PTHREAD_MUTEX_FAST_NP) and this
seems to work across processes sharing the lock, however the same
problem is there, that when a process holding the lock gets killed,
the lock isn't released. The recent robust futex work should deal with
this, but will be some time before it hits kernel + glibc.

Does anyone know if sysV IPC semaphores have any mechanism for recovering locks?

One mechanism to handle the process-crashing-holding-lock corner case
is to have lock acquisition timeout after eg 10s, and check if the pid
of the locker is still there - if not, the lock is dropped by 1.

Any comments on why this is a bad/unworkable idea with eg sysV semaphores?

> Volker Lendecke wrote:
> > On Sat, Apr 22, 2006 at 06:15:31PM +0100, Daniel J Blueman wrote:
> >
> >
> >>As a test, I changed the opening of the locking.tdb and brlock.tdb
> >>files to use the TDB_INTERNAL flag, avoiding use of the fcntl(F_SETLK)
> >>syscall for locking individual database records. Performance was a lot
> >>snappier, with quite a bit less system time used.
> >>
> >>What is the scope of implementing shared memory TDBs, where locking
> >>could be done simply on structures?
> >
> >
> > How would you implement cross-process locking without
> > any syscalls? Maybe Linux has some fancy stuff here, but for
> > most unixes we need to coordinate the mmap'ed area for the
> > tdbs fcntl locks.
> >
> > Volker
--
Daniel J Blueman