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:
> 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
> 2) Correct the bug that is present in Bill's current (generic)
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
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!
> 3) Optimize for each platform.
> Please give me your feedback about these issues.
> Thank you
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk