Messages in this thread | | | Date | Wed, 27 Jan 1999 12:25:32 -0500 | From | Arvind Sankar <> | Subject | Re: <asm/spinlock.h> issues |
| |
On Wed, Jan 27, 1999 at 08:17:03AM +0100, Ulrich Windl wrote: > > > > If two threads holding a read lock both try to upgrade to a write lock, > > they both deadlock. > > Hmm why: At the instant when only one thread has a read lock, you > could atomically exchange it with a write lock. As long as another > process has a read lock it's impossible. I don't see the deadlock.
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/
| |