From: Mike Kupfer (Mike.Kupfer@eng.sun.com)
Date: 01/10/00-06:33:08 PM Z
Message-Id: <200001110033.QAA258272@athyra.eng.sun.com>
Subject: "indivisible lock" semantics
Date: Mon, 10 Jan 2000 16:33:08 -0800
From: Mike Kupfer <Mike.Kupfer@eng.sun.com>
Spencer and I exchanged some mail last week about the fact that v4
locks are indivisible (i.e., they follow Windows semantics, rather
than Unix semantics). The rest of this message contains excerpts from
two messages that I sent to Spencer.
I'm not proposing a change to the protocol, but I would like to put
this on the table for discussion, to see if anyone has further
comments that might impact the protocol or spec. The reason I'm not
proposing a protocol change is that I think it's rare for Unix
applications to take advantage of "divisible lock" semantics. Given
the date, I think it's more important to move forward with what we
have.
Excerpt #1:
>>>>> "Mike" == Mike Kupfer <Mike.Kupfer@eng.sun.com> writes:
Mike> Page 58, Section 8.2.3: for a Unix client talking to a Win32
Mike> server, some entity, either the client or the server, has to
Mike> map a Posix locking request to (potentially) a series of
Mike> Win32 locking requests. The series of Win32 requests should
Mike> be atomic. For example, it is a legal Posix request to
Mike> unlock a hole out of the middle of an existing lock. The
Mike> Win32 API expresses this as removing the old lock and
Mike> creating two new ones. The atomicity requirement is that
Mike> nobody else create a conflicting lock between the time the
Mike> first lock is removed and the two new locks are created.
Mike> The I-D places this responsibility on the client, asserting
Mike> that it is easier for the (Unix) client to do this
Mike> conversion than it is for the (Win32) server. I think this
Mike> is false, particularly in light of the atomicity issue.
Mike> I don't see any simple ways to deal with the atomicity
Mike> issue. Fortunately, it's rare for a Unix application to
Mike> change subranges of an existing lock, so perhaps the
Mike> protocol need not provide an atomicity guarantee. If a
Mike> conflicting lock is created in the middle of a series of
Mike> "Win32" operations, the client could simply treat the lock
Mike> as being lost and notify the application.
Mike> So I guess I'm asking that the last paragraph of Section
Mike> 8.2.3 be rewritten to clarify this issue. Let me know if
Mike> you want help with specific verbage.
Excerpt #2:
>>>>> "Mike" == Mike Kupfer <Mike.Kupfer@eng.sun.com> writes:
Mike> Hmm, the more I look at the indivisible locks semantics, the
Mike> less I like them. Suppose you have two processes, A and B,
Mike> each of which has a read lock on a byte range. Now suppose
Mike> process A submits a blocking request (F_SETLKW) to upgrade
Mike> half the region to a write lock. You can do this with the
Mike> current NLM protocol. Process A simply requests the upgrade
Mike> and goes to sleep until the server grants it. With
Mike> indivisible locks, process A goes to sleep and wakes up
Mike> every now and then to see if there are conflicting locks for
Mike> the range. Once there are no more conflicts, process A can
Mike> release its lock and obtain the 2 new locks (one for the new
Mike> write-lock range, one for the remaining read-lock range).
Mike> Yuck.
Mike> Of course, a Win32 server would have to do something similar
Mike> if the protocol supported Posix-style locking. The
Mike> difference is that with indivisible locks, the client has to
Mike> poll the server. (Or I suppose it could submit a dummy
Mike> write lock request and wait for the server to grant it.)
Mike> With Posix-style locking, the server only has to poll the
Mike> local locking interace provided by the OS.
Mike> I guess the good news is that this can be considered unusual
Mike> behavior, and that most applications will not split up
Mike> existing locks like that.
Mike> Anway, here's a counter-proposal for the first replacement
Mike> paragraph that you suggested:
Mike> "The byte range of a lock is indivisible. A range may be
Mike> locked or unlocked between read and write but may not have
Mike> subranges unlocked or changed between read and write. These
Mike> are the semantics provided by the Win32 environment but only
Mike> a subset of the semantics provided by Unix environment.
Mike> This means that Unix clients may need to emulate a single
Mike> locking request with multiple NFS calls. For example, if a
Mike> subrange is unlocked, the client will need to unlock the
Mike> entire range and lock the new regions. This creates a
Mike> window during which a conflicting lock can be taken by
Mike> another client. If this happens, the server will reject the
Mike> client's attempt to create the new regions, and the client
Mike> will notify the application that the lock has been lost."
mike
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:59 AM Z CST