Subject: Lock upgrade semantics

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 12 Jan 2000 07:37:20 -0800

I earlier asserted that lock upgrade was not atomic
and that two competing upgrades could be resolved
because the upgrade was effectively done before 
attempting to get the write lock.  This arose out of,
but was distinct from, Mike Kupfer's issue about the
lock divisibility.  My assertions were based on
what I remembered (or thought I remembered) about
the flock implementation within Irix.

I've just tried this on a nunber of UNIXes (Solaris,
DEC/COMPAQ, LINUX) and find that EDEADLCK is returned
on all of them.  This indicates that on those systems
at least, upgrade is not handled as two separate state 
transitions.  So either I misremembered the Irix 
implementation or Irix is unusual in this regard.

Given this, my worries about upgrade in the current
protocol are misplaced.  Having upgrade on the server
return denial is OK since it is not necessary to
allow one of the two upgraders to succeed.

Never mind.

---

From: Mike Kupfer <[email-masked]>
Date: Thu, 13 Jan 2000 10:55:07 -0800

Okay, I think this leaves us with what to say about UNIX clients and
splitting locks.

I see the choices as

  1. if an application tries to split a lock, deny the request (e.g.,
  return EINVAL).

  2. If an application tries to split a lock, emulate it by dropping
  the original lock and creating 2 new locks, and hope that nothing
  bad happens.

  3. If an application tries to split a lock, emulate it, but notify
  the application if something went wrong.

I don't think choice 2 is acceptable.  It basically says that under
certain edge conditions it's okay for user data to get silently
corrupted.

If we can come up with a sufficiently strong way to detect that
"something went wrong", I could go with either 1 or 3.  Otherwise, I
think we should go with choice 1.  (And I'm afraid that so far I
haven't come up with anything I'm happy with for detecting that
something went wrong.)

Comments?

mike