Re: [flyweight] rw_locking policy patch for review

thanks for having a look at my patch ...

>   * 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:
>      · Thread A destroys the last flyweight associated to some value x.
>     check(h) passes as there are no more references and just when
>     factory. erase() is about to be called the thread is interrupted. ·
>     Thread B creates a flyweight with value x. · Thread A resumes and
>     the entry with x is destroyed leaving a dangling reference in B.

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: see for instance that you've got a fair amount of
>   code repetition across the insert() and erase() memfuns of the
>   different factories, this is precisely a sign that you can factor this
>   out, and the proper place (IMHO) to have it is in flyweight_core.

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 ...

> Apart from this the patch is nice and I'd like to use it as inspiration
> (with your permission) to enhance the lib in the future when rw locks