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

[David Collier-Brown]

    You can always check for a dead process if you save the
pid of the process which holds the lock.  Alas, this
is a slow operation, involving calling kill(pid, 0),
two process switches and a return.  As you
do relinquish the processor, that's not actually
evil, but is it something that conceivably could slow
you as much as the fcntl (;-))

   From some old measurements on my Sun, I **think** it's
faster than **my** fcntl... I really need to remeasure
with Solaris 10.

--dave

Daniel J Blueman wrote:
> 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
> 

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-5943