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.