Boost logo

Boost :

From: Tim Blechmann (tim_at_[hidden])
Date: 2008-01-22 05:26:45

> 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" ( ) and
> "Factory" ( ) 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 ).

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

Who need fossil fuel when the sun ain't goin' nowhere
  Amiri Baraka

Boost list run by bdawes at, gregod at, cpdaniel at, john at