OOFS

Chris Bitmead uid(x22068) Chris.Bitmead@Alcatel.com.au
Mon, 05 May 1997 15:21:58 +1000


>> The danger is that the semantics of an mmapped file suck as a proper
>> solution to the problem, and the lispvm people might get lazy and not..
>> The other thing is that you can't have object level locking with
>> page-mapped files which is essential for a working multi-threaded solution.
>
>My thoughts and investigations lead me to believe
>object-level locking is too fine-grained, for both the system to
>implement and/or the programmer to specify.

My experience leads me to believe that object-level locking is
essential and easy to specify.

Think about this. With an OOFS, you could be getting objects from disk
*anywhere* in your code. You don't always know where when, while
writing the code.

Now, Page level locking is non-deterministic. If you lock a page to
access an object, who the hell knows what else you've "accidently"
locked as well.

Thus, with page level locking, you can get a deadlock ANYWHERE in your
code. Are you smart enough to look through all the code you've written
in your life and work out what the hell you should do in a deadlock
situation for every single function call you've ever written?

Page level vs object level locking is not a performance issue. It's an
issue of whether you care if everything falls apart in a screaming
heap when you least expect it.

>Page-level locking is very fast and efficient which makes it the best choice.

Object level locking is also very fast and efficient. It is also
deterministic which makes it the best choice.

>It may produce less concurrency, but that isn't a high price to pay
>for the huge increase in single-threaded and read-only performance
>and the simplicity of the implementation.

Concurrency isn't the issue. False locking problems and false
deadlocks are the issue.

What you gonna do if someone "accidently" has a lock on an object they
don't care two hoots about?

>Given the entire SilkOS system uses persistent object system
>for almost everything, it must be fast and efficient.
>This isn't a UNIX thing, this is a hardware thing!

We all know standard hardware is pretty brain-dead. Unfortunately
that's something we just have to live with.