[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multi-threaded Readers/Writers Lock



On Sun, Sep 09, 2001, mulix wrote about "Re: Multi-threaded Readers/Writers Lock":
> (possible sceario for multiple/multiple locking: assume you have a
> scenario where multiple reading OR multiple writing is allowed at the same time
> (multiple writing is allowed because it is synchronized at a lower
> level)).

I still think that since writers are also allowed to read (this is usually the
sense in which "writers" are used - e.g., a task wishing to increment a
variable is a "writer"), a lock which allows concurrently any number of
threads to write is equivalent to one which allows any number of threads
to concurrently either read or write (or any combination thereof), and that
is simply equivalent to not having any lock at all...

Maybe a multiple writers lock is useful when there is a clear seperation
between read and write operations, and writers can't read (e.g., in a
Unix filesystem in which the write() operation cannot read), but I can't
think of any example at the moment.

> > Typically recursive locking is not needed in well-written programs, and
> 
> we can debate the well written part, but i agree that a clear design
> should make recursive locking unnecessary. however, not all designs are
> good, and sometimes you have to "multi thread enable" a single thread
> design, where some design choices which were good in tthe original
> scenario make your life a living hell.

Yes. And watch out for deadlocks if you build on such a bad design... :(

> consider a case where due to delayed initialization of the data structure a
> "read"  request must actually be protected from other concurrent read
> requests, since it  causes the data structure's state to change,
> effectively making it a write request. a neat optimization, but it
> makes such "upgradability" necessary...

It is not necessary, just useful for more efficiency and better concurrency.
It is not necessary because you can always relinquish the read lock, and wait
again for a write lock. When you wake up with the write lock you should
remember that the situation may have changed since you held the read lock
(some other writer might have gotten the write lock before you!) - so you must
do the read again and check again if the write operation is still necessary.
If it isn't, just complete the read as usual and relinquish the lock; In this
case you have just wasted some CPU time with only one thread running with the
lock with other readers unnecessarily blocked - this is what I meant when I
said such upgradeability is useful for better concurrency.

By the way, (and quite off-topic for a Linux mailing list),
Now that I think about it, I'm not sure how such an "upgrade" can be guaranteed
to work. What happens when two readers are reading concurrently, and then both
of them decide to "ugrade" to write? Which one will get this privilage? What
will happen to the second one - there is no way it can get a write lock
without another task (the first reader) getting a chance to write first?
If an upgrade cannot guarantee that no writer got a chance to write before
you, then it is useless mechanism - you could have just relinquished the read
lock and waited on a new write lock (as I explained before), and that's it...

-- 
Nadav Har'El                        |        Sunday, Sep  9 2001, 21 Elul 5761
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Hospital: Where they wake you up to give
http://nadav.harel.org.il           |you a sleeping pill.

=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il