Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety

[Paolo Carlini <pcarlini at suse dot de>]

Hi Phillip,

> Peter Dimov wrote:
>  
>
> > The TR1 generators have no hidden global state as far as I know, so they
> > (ought to) provide the usual "basic thread safety". :-)
> >    
> Right, I've now gone back to working on this, and have significantly
> modified the testcase to improve coverage. I didn't verbatim copy the
> boost algorithm that was posted, as I didn't think it stressed the code
> for potential race conditions enough.
>
> The attached patches against trunk and v7 are ready to be committed as
> far as I'm concerned. I've got write access now, so I just need an 'OK',
> and I need to know which branch(es) to commit to.
>
> The testing code uses a TR1 Mersenne Twister RNG for each thread. The v7
> branch doesn't seem to have the TR1 random bits, simply copying them
> across seems to work though, so I created my patch under the assumption
> that it will be copied across.
>  
apparently Benjamin also likes this approach, therefore, in general, I 
would say let's go ahead for mainline and test it there on more arches: 
in case of problems we have time to revert it for 4.2.0 and, in any 
case, the "stability" requirements for tr1 are "special". Anyway, I just 
tested it on 4-way ia64-linux too.

My only minor nit would be double (instead of triple) underscore for 
__enable_shared_from_this; I would suggest renaming __lockless to 
_S_lockfree and also __locks to _S_mutex and __unsafe to _S_single; 
maybe _Locking_mode is better  english than _Lock_mode (your call...) 
Maybe Benjamin wants to help here (*)...

Of course, before the final approval, please post a ChangeLog entry 
(have a look to ChangeLog about the style. You can certainly group 
functions which are only renamed).

Paolo.

(*) For the curious, the story went that I quickly drafted something in 
private email with Philip, without paying much attention to English and 
consistency with other names in the library, my fault...