From: JOAQUIN M. LOPEZ MUÑOZ (joaquin_at_[hidden])
Date: 2008-07-06 17:25:40
De: boost-bounces_at_[hidden] [boost-bounces_at_[hidden]] En nombre de Tim Blechmann [tim_at_[hidden]]
Enviado el: domingo, 06 de julio de 2008 12:33
Asunto: Re: [boost] [flyweight] rw_locking policy patch for review
> > * The error is in flyweight_core::erase(). You have moved the
> > invocation to check(h) outside of the write lock, which can cause a
> > race condition:
> i see your point ... double-checking before erasing value x should work
> around this issue ...
> > * The design issue has to do with your moving all the knowledge of the
> > locks to the factory itself. As I envision the design, all the lock
> > stuff should be made by flyweight_core and factories should be kept as
> > dumb as possible
> i see your point, it would be possible to extend the factory api with a
> find() memfun ...
> i didn't do that for now, since i think, this way certain factories could
> implement an more efficient insert() than a combined find()/insert()
> pair ...
Well, there's always that tradeoff lurking in... I prefer to keep the design
orthogonal and risk losing that potential improvement (which hopefully
would e minimal if it existed).
> > My last request is: now that you've got rw locks implemented is a very
> > good opportunity to test them agains traditional locks in the context of
> > Boost.Flyweight and see how they compare (after all, if the gain is not
> > significative maybe rw locks shouldn't be used after all). Do you plan
> > to write some performance tests of rw against traditional locks? That
> > would be terrific.
> sure, i could try to implement a small performance test for
> boost.flyweight to compare unique locks with shared locks ...
Nice! Please keep me informed, and do not hesitate to contact me if
you need assistance in the process. I'm very curious to know the
actual degree of performance improvement rw looks can bring about.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo