TDB locking overhead and performance...
davec-b at rogers.com
Sat Apr 22 18:56:59 GMT 2006
Linux indeed hs some fancy locks for this, which were tested
with TDBs (see
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).
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.
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
More information about the samba-technical