From: Tim Blechmann (tim_at_[hidden])
Date: 2008-01-22 05:26:45
> so that we can follow this protocol:
> readwrite_lock l(mutex);
> if(h=find(x))return h;
that is similar to my implementation ...
> An approach to convering both simple and read/write locks would be to
> extend the concepts "Locking Policy" (http://tinyurl.com/ypvy4l ) and
> "Factory" (http://tinyurl.com/2er6dl ) to "ReadWrite Locking Policy" and
> "Lookup Factory", respectively, and only when the components specified
> both conform to the extension concepts would we internally follow the
> readwrite protocol instead of the simple one. I think I can work this
> out, but I'd prefer to put this in the "Future work" section rather than
> trying to implement it immediately, so as to gain some more feedback and
> wait for read/write locks to be brought back into Boost (they were
> removed due to an implementation bug, see http://tinyurl.com/2clcr9 ).
that would be fine with me ... it would definitely make sense to wait for
the reader-writer locks in boost.thread ...
>> > * Did you try to use the library? With what compiler?
>> > Did you have any problems?
> Given that you are already using a lib of your own around the same
> concept, I think it would be very interesting if you could try replacing
> that with my lib and report whether the experience is smooth enough --in
> particular, if you're using read/write locks you can measure whether
> thery make an actual diference wrt to candidate Boost.Flyweight simple
since my class shares the same concept add the same interface, they can
probably changed by changing a typedef ...
i am not sure, whether at the moment rw-locks make a big performance
difference for my application, mainly because most of the objects are
allocated from a single thread ... that might change in the future,
-- tim_at_[hidden] http://tim.klingt.org Who need fossil fuel when the sun ain't goin' nowhere Amiri Baraka
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk