Re: [boost] [thread] Roadmap for RW locks ?

From: John Maddock (john_at_[hidden])
Date: 2006-10-31 04:52:31

Roland Schwarz wrote:
> Having tried to catch up with the last RW-lock discussion I am
> left wondering what is the conclusion of the discussion.
>
> In thread_rewrite there is an implementation from Anthony.
> This however currently is only for windows so far, correct?
>
>
> As I do understand the problem (please correct me if I am wrong)
> there is not a single reader-writer problem, but three:
>
> 1) reader-priority rw-access
> 2) writer-priority rw-access
> 3) starvation free rw-access
>
> which of these three cases applies is in the application domain
> and not in the domain of the library implementation.
>
> Consequently a generally usable library would need to provide
> mutices for all three cases. I can see this as a policy that
> is fed to the ctor of the rwmutex in the original draft of Bill Kempf:
>
> writer_priority,
> reader_priority,
> alternating_many_reads,
> alternating_single_read
>
> I cannot see however a similar policy parameter in thread_rewrite
> version. How is this getting controlled in this case?
>
> Glancing over Anthonys code I can see that he is making use of
> some atomic primitives and semaphore calls. So I think this should
> be portable fairly easy.
>
> However, since rw-mutices can be made of a mutex and some condition
> variables, shouldn't we follow the old principle of getting it
> correct first and optimize later? I'd very much like to see this
> happen. Not only is the generic version valuable as a fallback, but
> also as a reference to measure performance and correctness against.
>
> I propose the following roadmap:
>
> 0) Decide if we want the current (broken) version in 1.34.
>    Please note that this is URGENT. (A previous poll about this
>    interestingly did not get answered by anyone.)

Apologies, but I think you know my vote: if it was too broken to go in 1.33 
then we shouldn't have it in 1.34.  When it resufaces there will be an 
expectation that it has actually been fixed.

> 1) Decide if the current interface proposed by Bill Kempf still is
>    appropriate.
>
> 2) Correct the bug that is present in Bill's current (generic)
>    implementation.

Is this the version that is in mainline cvs or something else?  I ask 
because the version in current cvs was (all IMO) far too clever for it's own 
good: it hasn't been fixed because frankly, the design was such that it was 
hard, verging on impossible to fix.

I'd much rather see a simpler interface with a lean and mean implementation 
that a mear human stands a chance of verifying as correct.  Remember we 
can't rely on testing to verify correctness, we need to be able to analsise 
the code.

BTW: I'm not criticising you guys over this: I actually think you've done a 
really impressive job rewriting and analysing the threading code!

Regards, John.

> 3) Optimize for each platform.
>
> Please give me your feedback about these issues.
>
> Thank you
>
> Roland
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost