OOFS

[Chris Bitmead uid(x22068)]

Kelly,

I've been thinking about what you were saying about object level
locking to be inefficient to implement.

I can sort of see what you mean, in a language like Lisp where
everything looks like a pointer to an object. Let me put forward a
compromise plan...

I'm still concerned about the scenario where you won't be able to read
your email because your email object happens to be stored on the same
page as someone else's email object, and they happen to be reading or
deleting their email at the same time.

Let me also make a few observations about locks. Under UNIX for
example, not many things bother with using locks. The number of
situations where locks are useful seems to be limited to a few well
defined situations. For example, wanting to read email at the same
time as the system is loading down new email.

Another observation about locks in a Lisp system, is that locks are
really only interesting when there are people changing objects. As we
know, nice lisp code is very functional, and there won't be a great
deal of objects in the system that are being updated.

In summary, therefore I think that locking isn't something you
probably want to have most of the time.

Therefore I propose this. We support two compatible locking schemes...

Scheme 1:- The default way to access objects will be via NOLOCK. When
you intend to update an object you explicitely ask for a write lock on
an object up-front. Something like 
(get-obj-with-write-lock (find-mail-of-user "ChrisB")).

This will return the particular object after first getting a lock.

Now remember that for example, in the case of reading your email, you
only really want a lock on the top level collection that holds all
your email. You don't need to lock every individual item of email, and
let's say for example you implemented each item of email as a
structure, with "from", "to" and "message" components. You wouldn't
want to lock each component either. All you want to lock would be the
top level collection of email items for two reasons - 1) So that the
system doesn't update the list while you're updating it and 2), if
you're silly enough to run two email readers at once they can't
overwrite each other.

Therefore the system would be efficient because even a complex mail
reader program probably only needs to have one explicit lock
statement. Everything else uses NOLOCK and doesn't worry about it.

Scheme 2:- Being the scheme you proposed of automatic page level
locking. Locking a page would automatically effectively lock every
object located on that page.

Personally I'm not sure where I would bother using Scheme 2, but
there's no reason you shouldn't support it I guess.

What do you think?

Chris.