> (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/