On Mon, Sep 21, 2009 at 04:35:08PM +0100, Guido Trotter wrote:
> On Mon, Sep 21, 2009 at 4:14 PM, Iustin Pop <[email protected]> wrote:
> >
> > So, I have yet to see how the non-blocking lock acquire changes, but I would
> > like to raise some issue that might or might not be solved by that code.
> >
> > Basically, we have around four usual ways of acquiring locks:
> > ① single node or single instance
> > ② multi-node or multi-instance
> > ③ set of instances and set of nodes (independent of one another, and rare
> > except all)
> > ④ set of instances and their associated nodes
> >
> > ① is the only one which, today, can't create locking issues. ② is simple
> > to fix so that it doesn't create issues (simply abort if not all can be
> > acquired). But ③ and ④ have issues due to their multi-step approach
> > (based on locking levels).
> >
> > I think that unless we solve the multi-step approach (again, the new
> > design might solve it but I don't know how), we will still have
> > problems.
>
> Not if we can rollback all steps, if the second one fails.
> (so the rollback can also be done on more than one level, rather than
> on only one).
> (I think the design hansmi sent last week has this).
Yes, but if we do all in one step, we don't need even the concept of
"rollback".
> > Therefore, I think that allowing the locking library to
> > understand "lock all of this set of nodes and instances", in a single
> > step, and "lock these instances and their nodes", is a better way to
> > solve the locking issue than changing lock acquire to nonblocking.
>
> This we could solved in the GanetiLockManager level, but it depends
> how do we want to tie this with the config, because of the "what
> instance are associated to what nodes?" question. It might be not
> necessary though.
ACK.
> > If the above is done, then I don't think we need many changes to e.g. a
> > SharedLock itself. All that is needed is the answer to the question: can
> > I grab this set of locks (atomically).
>
> In order to do this you still need try-locking or timeouts in a shared
> lock. So some changes are needed anyway (currently only blocking
> acquire is supported). The timeout gives you an option to try "for a
> while" without still slowing down more than necessary other
> operations.
Yes, but no in the sense of sleep-with-wakeup and similar. All we need
is a structure mapping lockable items to owners, and:
self._lock.acquire()
try:
if utils.all(has_no_owner(items_to_lock)):
for item in items_to_lock:
owner = target
return True
else:
return False
finally:
self._lock.release()
That would be all that is needed if the LockManager can deal with all
the needed data. We don't need notifications.
iustin
