process shared robust mutexes for tdb

Ira Cooper ira at
Mon Dec 24 07:43:07 MST 2012

Mutexes over mmap is actually fairly portable.  It is the robust mutexes
over mmap that become less so.  But even then, I know 2 platforms that
support them.  The Solaris/illumos family, and Linux.  That's not TOO bad.

The numbers he's showing are not that unrealistic at all.  I've ran similar
benchmarks.  The ability to decrease the cost of the locking primitives,
and potentially avoid the context switch is pretty darn big.

If you are wondering about "Why not transactions" look at my tdb.git and
the locking branch.  The work is incomplete, and I'll admit a mess, in an
attempt to make transactions work.  Volker wisely chose against this
approach.  (Or he had the benefit of reading my disaster.  One of the two!)

My only comment is: Volker, how are you handling "record" locking and not
chain locking?  That was one part I never got 100% right.  (And on solaris
using a mutex for everything is going to make someone cry... probably me.)

simo: Does LDB use transactions?  I thought it did?


On Mon, Dec 24, 2012 at 9:06 AM, simo <idra at> wrote:

> On Mon, 2012-12-24 at 11:39 +0100, Volker Lendecke wrote:
> > Hi!
> >
> > Under
> >
> >;a=shortlog;h=refs/heads/tdb
> >
> > find my current work in progress to augment the fcntl locks
> > in tdb with mutexes for the freelist and hash chain locks.
> > The reason for this is that fcntl under load pretty much
> > collapses. I don't have exact results yet, but the initial
> > tests for tdbtorture are spectacular. One test went down
> > from 8m47.470s to 0m13.376s. The tdb_open_ex patches are far
> > from done. I am still thinking how to protect tdb with
> > mutexes from other use. The idea is that this scheme is only
> > used for highly contended tdb like locking.tdb where we
> > don't do transactions for example.
> >
> > Comments?
> Looks nice, the only comment I really have is that mutexes over mmap
> memory are not very portable, but if mutexes can be used only on
> platfroms that cna properly handle them on mmap it is a very neat
> optimization for those platforms if it gives the numbers you show.
> Certainly beats having to make syscalls into the kernel constantly so
> I'd like to see this work hitting master once it's ready.
> I would love to see numbers for LDB too, we've seen quite a hit with
> fcntls in the past, although I guess fsyncs will dwarf any fcntl given
> we use transactions a lot.
> Simo.
> --
> Simo Sorce
> Samba Team GPL Compliance Officer <simo at>
> Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list