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

[Serge Hallyn]

Quoting Dwight Engen (dwight.engen at oracle.com):
> I think the names you've got are fine (don't really have a better
> idea), I do think its good to name locks by what they cover. Its a bit
> tricky here because one is a process (and thread) lock and the other
> is just a thread lock and it would be nice to convey that somehow.
> 
> In thinking about this a bit, the memlock and the pthread mutex are
> really the same (a thread lock), they just cover different regions (ie.

Agreed, so we should have 3 lock functions.  Actually, for clarity the
two could be lxc_container member functions, so there would be:

	task_lock();  // or process_lock()
	c->mem_lock(c);
	c->disk_lock(c);

> in memory struct lxc_container vs process data). The sem_t could just
> as easily be a pthread_mutex_t or vice versa, I think they're built on

Agreed, I'd like to make that change - after other things settle down.

> the same primitives in glibc. One reason for potentially switching the
> sem to a pthread mutex is if we decide to expose the locking in an api
> we'll almost certainly want to use robust locks.
> 
> I wonder if something like this is any clearer?
> 
> extern int lxclock(struct lxc_container *c, int type);
> 
> lxclock(c, LXC_LOCK_DISK);	-> flock c->slock
> lxclock(c, LXC_LOCK_MEM);	-> pthread/sem lock c->privlock
> lxclock(NULL, LXC_LOCK_PROC);	-> pthread/sem lock whole process

Right now I feel like it'll be clearer to have different function
names for each type of lock - mainly because I think it takes less
visual/mental processesing while looking at a chunk of code to
know which lock is in use.  But I may be thinking wrongly...

> I don't know if this is any clearer or not, but I do think its a bit
> bad to have thread_mutex exposed and not wrapped.
> 
> > > I think I'll have a few more comments/questions after I read
> > > through the rest of the patch.
> > 
> > Excellent, thanks.
> > 
> > -serge
>