POSIX Locking (some pointers for those not already scared)

Jeremy Allison jra at samba.org
Fri Mar 2 17:28:35 UTC 2018


On Fri, Mar 02, 2018 at 08:27:18AM +0100, Volker Lendecke via samba-technical wrote:
> On Fri, Mar 02, 2018 at 04:24:39PM +1300, Andrew Bartlett via samba-technical wrote:
> > G'Day,
> > 
> > I've been working to understand locking, fork() and tdb as we move
> > Samba to LMDB.  I had some fears before I realised that an fcntl() lock
> > is not kept across fork(), so the stupid behaviour on close() doesn't
> > matter if it is in the child.
> > 
> > It also doesn't matter that tdb_reopen_all() keeps the FD, as while the
> > file offset is shared (we work around this), the locks are not.
> > 
> > Others may not be aware of the standard rant about POSIX locking,
> > specifically:
> > 
> > https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html
> > http://0pointer.de/blog/projects/locking.html
> > http://0pointer.de/blog/projects/locking2
> > 
> > It is worth a read if you don't mind putting your brain though a
> > blender.
> 
> You have no idea of the fun I had when working on tdb mutexes. In
> particular ctdb really plays hardball with everything around locking
> in tdb.
> 
> What those blog posts completely miss: fcntl locking in Linux does not
> scale *AT* *ALL*. I haven't really tortured Jeff's fd-based locking
> yet, but every single fcntl operation system-wide in the past went
> through one single spinlock. Not sure this is still the case, but it
> fully kills performance if you start using it.

Well it's not just Linux :-). As far as I know fcntl locking
in *all* POSIX systems doesn't scale.

It's to do with being able to report EDEADLK I believe. In
order to correctly do that you have to have a snapshot of
the complete state of all locks on a file (I believe Jeff's
file description locking doesn't ever report EDEADLK, but
I'd have to check the source code to be sure).



More information about the samba-technical mailing list