Messages in this thread | | | Subject | Re: <asm/spinlock.h> issues | Date | Wed, 27 Jan 1999 10:25:46 +0100 | From | Helge Hafting <> |
| |
> 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 deadlock is simple: 1. Two processes has read locks. 2. Both want to upgrade to write lock. 3. Both wait forever for this, as the other aren't going to release the read lock until it has finished using the write lock it doesn't get.
> (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. Exactly, and this solves the problem outlined above, like this: 1. Two both processes have read locks 2. Both want the write lock 3. Both release the read locks 4. Both tries to grab the write lock 5. One gets the write lock, the other is forced to wait until number one release it again. No deadlock.
You could have an upgradeable non-deadlocking lock if you make the upgrade mechanism drop the read lock when some other process also is trying to upgrade. This hovewer is unnecessary complication, and it is dangerous because it isn't natural to assume that the upgrade option might drop the lock letting another process mess with the data in the meantime.
Helge Hafting
- 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/
| |