________________________________________ De: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] En nombre de Tim Blechmann [tim@klingt.org] Enviado el: domingo, 06 de julio de 2008 12:33 Para: boost@lists.boost.org 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 ...
Yep.
* 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