Re: Exclusive Locking ... per lock type?

What Jim says is all reasonable, but cannot currently be inferred from
the working in 2518.  I'd suggest this be added to the issues list.

In particular, I think it is reasonable for 2518 to say that an exclusive
lock for a given locktype MUST not coexist with another lock of that same
locktype.  This gives a reasonable minimal semantics to "exclusive",
while letting additional locktype specific semantics to be defined.

Cheers,
Geoff

   From: Jim Whitehead <ejw@ics.uci.edu>

   > Did section 8.10.6 of 2518 meant to say that an exclusive
   > lock will fail if there already is a lock *of that locktype* on that
   > resource, or if there is *any* exclusive lock there?

   The intent was for the exclusivity to apply per locktype.  So, for example,
   an exclusive read lock would not affect taking out an exclusive write lock.
   However, it is possible to imagine lock types that would have semantics that
   are not orthogonal to existing locks.  For example, while read and write are
   pretty orthogonal, and hence exclusive read and exclusive write locks can
   co-exist happily on the same resource, a hypothetical "read/write" lock type
   would interfere with both a write lock and a (equally hypothetical) read
   lock, and in this case I would expect a request for an exclusive read/write
   lock to fail if there is either a shared read lock, or a shared write lock,
   or an exclusive read lock, or an exclusive write lock on the resource.

   So, the best answer is, when defining a new lock type the interactions of
   the new lock type with all existing lock types needs to be taken into
   consideration when creating the lock compatibility table.

Received on Tuesday, 28 December 1999 00:22:09 UTC