process shared robust mutexes for tdb

[simo]

On Mon, 2012-12-24 at 09:43 -0500, Ira Cooper wrote:
> 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.

Well I do not really care for any other platform than Linux, but we
historically cared for having samba run on at least Linux, *BSD and
Solaris and some other Unix, although all the others seem to be dead or
moribund now.

> 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.

I believe those numbers are quite real indeed, context switches are a
huge slow down with a pattern like the one used in our TDB files.

> 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!)

Transactions require fsyncs, which are inherently orders of magnitude
slower as they need to hit platters. It's true that with SSDs and other
Flash tech, disks are not too slow, but I do not think TDB is optimized
for SSDs access patterns, so there will be other slowdown factors there.

> 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.)

Shouldn't it just be a matter of replacing every fcntl lock with an
equivalent mutex ? What's harder about chain locks ?

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

It does by default on every write operation.

Simo.



-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>