Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-30 17:16:42


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

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.

3) Optimize for each platform.

Please give me your feedback about these issues.

Thank you

Roland


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk