Messages in this thread | | | From | "Ulrich Windl" <> | Date | Wed, 27 Jan 1999 08:17:03 +0100 | Subject | Re: <asm/spinlock.h> issues |
| |
On 26 Jan 99, at 12:02, Mark Jefferys wrote:
> On Thu, Jan 21, 1999 at 08:15:48AM +0100, Ulrich Windl wrote: > > % But another thing came into my mind: In theory it seems a good idea > % to have upgradable and downgradable spinlocks: > % > % Upgrade: Change from read lock to write lock without loosing it > % temporarily > % > % Downgrade: Change from write lock to read lock > > % The advantages I see: more concurrency. I don't see additionaly > % dangers of deadlocks here. (But I can be wrong) > > 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.
(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)
> > 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.
> > In other words, the lock can have at most one special guy who is allowed > to transition between the write and read states, while everyone else can > at most hold and release the read state.
But why? As you don't know how long the priviledged thread would hold the lock in read state, you would be denying other threads the right to hold a "read lock with the option to upgrade". In addition, the priviledged process might never upgrade to a write lock.
I'm no SMP guru, but I think you are making things unnecessarily complicated here.
Regards, Ulrich
- 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/
| |