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

Re: Multi-threaded Readers/Writers Lock



On Sun, 9 Sep 2001, Nadav Har'El wrote:

> On Sun, Sep 09, 2001, mulix wrote about "Re: Multi-threaded Readers/Writers Lock":
> > do you need single writer multiple readers, or multiple/multiple? do you
>
> What's a multiple-writers multiple-readers lock? If you allow
> multiple writers concurrently, then why not allow reading in the
> same time too? Remember, writers are also allowed to read! So now,
> if you allow multiple concurrent writers *and* readers, why do you
> need a lock at all?

i can think of theoretical reasons why such a lock would be necessary,
although all of them are far fetched and i never ran into them in real
life. shlomi did ask for a readers/writer_s_ lock, so i asked for a
clarification.

(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)).

> The usual readers/writers lock, as far as I know, is one that allows several
> readers to read concurrently, but only one writer to write at a time (when
> the writer is writing, readers are blocked too).

correct.

> Typically recursive locking is not needed in well-written programs, and
> the "upgradability" feature you outlined isn't necessary (though the latter
> can come in handy to improve concurrency in some circumstances).

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.

consider for example two things i ran into - a callback function which
might, or might not, be called with a lock already held.... also,
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...

> > > Does anybody knows of a ready-made ANSI C implementation?
>
> It is not hard to write such a thing yourself, using mutexes and condition-
> variables (the latter are essential to implementing a lock like you want).
> But knowing a little of the theory behind it is recommended. If you're
> looking for a good course in the Technion on this and related issues, try
> "Parallel and Distributed Computing", given (or at least used to be given)
> by the CS department.

it's not hard to write, but it does require a lot of thinking to write
_correctly_, especially if you need recursive locking and
"upgradability" (yes, i am speaking from experience.)

> Anyway, I bet that dozens of ANSI C implementations exist (if only as examples
> in courses and/or pthread books), but I am afraid I don't know one to point
> you too. Did you try googling?

i have written a (pretty good, imho) implementation, as i hinted in my
original email to shlomi. however, it's part of a very big proprietary product
and i cannot publish it (i asked). i can, however, help write from scratch such an
implementation, based on what i learned writing the closed source one. i
estimate it in no more than a few hours of work.
--
mulix

http://www.advogato.com/person/mulix
http://www.sf.net/projects/syscalltrack



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