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