so that we can follow this protocol:
readwrite_lock l(mutex); l.read_lock(); if(h=find(x))return h; else{ l.unlock(); l.write_lock(); h=insert(x); }
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?
no
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 locks.
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, though ... cheers, tim -- tim@klingt.org http://tim.klingt.org Who need fossil fuel when the sun ain't goin' nowhere Amiri Baraka