Subject: Exclusive Locking ... per lock type?

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 27 Dec 1999 16:39:17 -0500

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?

I can see arguments for both directions, and implementors  probably haven't
thought that much about it since everybody is just doing write locks,
but I assume the authors had one or the other in mind?

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 27 Dec 1999 14:52:02 -0800

> 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.

- Jim

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 28 Dec 1999 00:22:00 -0500

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 <[email-masked]>