The situation is there _are_ two threads, both trying to upgrade:
thread 1 blocks waiting for thread 2 to release its lock, and thread
2 blocks waiting for thread 1 to release its lock. Neither will, so
*boom* two cpus taken out.
>
> (Compare it to the situation when the thread has a read lock and
> wants to have a write lock. It would release the read lock
> temporarily, then try to grab a write lock. The difference is that
> some other thread could go between possession of the read lock and
> grabbing of the write lock. (Thus the first thread in discussion
> would grab a write lock right from the start) I see no other dead
> lock as in the situation when one own a read lock, and another wants
> to have a write lock, i.e. none)
The fact that the thread releases its read lock before trying to get a
write lock is what prevents deadlocks.
>
> >
> > Downgrading (without losing the lock) is safe, however.
> >
> >
> > It is possible to add a special read state (X) that can only be held once
> > at a time, and is (like normal read) incompatible with an active write
> > lock. Transitions between X and W are safe, as is a transition from
> > either to R.
>
> Your state X would prevent multiple threads from owning a read lock;
> my solution would not. In my solution the process wanting to upgrade
> would have to wait until all other threads have released theit read
> locks. I'm usure what your solution would imply. Not having to wait?
> Then it's actually a write lock with a different name.
It gets us a little more concurreny: one thread can hold an X lock instead
of a W, so it allows threads which are sure they only want to read to run
simultaneously. A W would prevent that. Since two threads can't have an X
together, we have no deadlocks.
Just my $0.02,
-- arvind
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/