[lxc-devel] [RFC PATCH] lxclock: Replace named sempahore with flock

[Dwight Engen]

On Fri, 24 May 2013 08:23:57 -0500
Serge Hallyn <serge.hallyn at ubuntu.com> wrote:

> Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
> > The problem: if a task is killed while holding a posix semaphore,
> > there appears to be no way to have the semaphore be reliably
> > autmoatically released.  The only trick which seemed promising
> > is to store the pid of the lock holder in some file and have
> > later lock seekers check whether that task has died.
> > 
> > Instead of going down that route, this patch switches from a
> > named posix semaphore to flock.  The advantage is that when
> > the task is killed, its fds are closed and locks are automatically
> > released.
> > 
> > The disadvantage of flock is that we can't rely on it to exclude
> > threads.  Therefore c->slock must now always be wrapped inside
> > c->privlock.
> > 
> > This patch survived basic testing with the lxcapi_create patchset,
> > where now killing lxc-create while it was holding the lock did
> > not lock up future api commands.
> 
> Two more notes:
> 
> 1. the new lock doesn't support timeouts like the old one did.
> There's no caller which is currently using timeouts, so I will
> probably remove timeouts from the private semaphore as well.
> 
> 2. It doesn't seem necessary to require everyone to understand
> the details, so I may abstrace away knowledge of c->privlock
> and c->slock behind two helpers.  Not sure what good names would
> be, maybe c->memlock() and c->disklock() ?  c->threadlock()
> and c->globallock()?  Something to indicate that the first is
> to protect the struct lxc_container from simultaneous updates
> from other threads, while the latter is to protect the on-disk
> container.

That would be nice. I'm not sure this is what you're getting at but it
would also be nice if the caller didn't have to know they needed the
thread lock before going for the disk lock (as a result of the
primitive we're using for the disk lock). So getting the disk lock
would automatically acquire the thread lock for the caller.

I think I'll have a few more comments/questions after I read through the
rest of the patch.

> -serge
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring
> service that delivers powerful full stack analytics. Optimize and
> monitor your browser, app, & servers with just a few lines of code.
> Try New Relic and get this awesome Nerd Life shirt!
> http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________ Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel