This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: "Phillip Jordan" <phillip dot m dot jordan at gmail dot com>
- Cc: "Paolo Carlini" <pcarlini at suse dot de>, libstdc++ at gcc dot gnu dot org
- Date: Tue, 22 Aug 2006 17:44:31 +0200
- Subject: Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety
- References: <44AD1E9B.4070801@gmail.com> <004401c6a111$5844d5e0$6701a8c0@pdimov> <44AF05EF.3060000@gmail.com> <44AF0BAC.3080908@suse.de> <44AF0DC9.5000102@gmail.com> <003301c6a231$ea929510$6407a8c0@pdimov2> <44BEB0E2.9060104@gmail.com> <44C3D62D.60504@suse.de> <4dc0430c0607260440r26caf1bew5bb2a8b2235e274b@mail.gmail.com>
Let's get this in.
> > 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 (*)...
I think this sounds good, it's more consistent with other usage.
You could also use _Lock_policy.
However, we can do the fine-tuning in-situ.
-benjamin