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