On Thu, May 03, 2001 at 02:10:48PM +0200, Trond Myklebust wrote:
> >>>>> " " == Matthew Wilcox <[EMAIL PROTECTED]> writes:
>
> > I'll get to it this weekend then. Should be a relatively
> > simple patch. Are there any other semantics you want changing
> > from the POSIX lock? I'm thinking of removing deadlock
> > detection, for one...
>
> What do you mean by `removing' it? Eliminating deadlock detection
> entirely will get you in deep trouble when you add mandatory locking.
Huh? (1) I don't intend to have mandatory locking on these new locks.
(2) how exactly would it get me into trouble?
Let's just go over the semantics we currently have for posix locks,
and see if we can come up with `better' lock semantics.
POSIX locks are advisory (unless you do the mandatory lock dance),
and apply to a byte-range. They are checked for deadlock, merged with other
compatible locks (same PID, same `owner'). (this seems redundant and there's
a question mark by it in the source... never mind.)
The POSIX locking rules mean that you can do funky things like:
lock bytes 0-100
lock bytes 50-150
unlock bytes 50-150
and you have bytes 0-49 left locked. of course, you can then unlock
bytes 0-100 and it will remove the lock from 0-49, but this behaviour
seems unintuitive.
You can also (and this causes a fair bit of ugliness in the kernel code)
do:
lock 0-100
unlock 25-75
or, even worse
lock_read 0-100
lock_write 25-75
which leaves you with 0-24 read-locked, 25-75 write-locked and 76-100
read-locked.
i can't imagine this is behaviour people actually use/desire. So for
a new lock type, i propose the following semantics:
byte-range, advisory, non-merging, non-deadlock-checking
Another semantic issue I want to tie down. Is it useful for different
threadsd to be able to share a lock? Or should locks from different
threads conflict? I'm currently leaning towards the latter, but you
may be able to convince me I'm wrong.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
