This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch] Make std::tr1::shared_ptr thread-safe.
- From: Alexander Terekhov <alexander dot terekhov at gmail dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: Peter Dimov <pdimov at mmltd dot net>, Jonathan Wakely <cow at compsoc dot man dot ac dot uk>, libstdc++ at gcc dot gnu dot org
- Date: Tue, 29 Mar 2005 18:18:04 +0200
- Subject: Re: [patch] Make std::tr1::shared_ptr thread-safe.
- References: <OF51216141.374EAC91-ONC1256FD3.00537529-C1256FD3.005361E0@de.ibm.com> <e52efbe105032907371ce02f72@mail.gmail.com> <4249794B.9040703@suse.de>
- Reply-to: Alexander Terekhov <alexander dot terekhov at gmail dot com>
On Tue, 29 Mar 2005 17:50:35 +0200, Paolo Carlini <pcarlini@suse.de> wrote:
> Alexander Terekhov wrote:
>
> >[... __release/acquire_memory_barrier() ...]
> >
> >>The only reliable implementation of these barriers that I see
> >>is an empty pthread_mutex_lock/pthread_mutex_unlock pair.
> >>
> >>
> >Nope. That won't work.
> >
> Sorry about the trivial question (I'm not MT expert, at least not 'til
> today: thanks for the helpful messages!): won't work in principle or
> won't work *given the classes of optimizations* implemented in the
> current GCC generation?
It won't work on Itanic (with pthread_mutex_lock/pthread_mutex_unlock
impls NOT injecting "mf") even if GCC would "implement" all sorts of
MT constraints as full-stop bidirectional asm-volatile-with-memory-
clobber-or-whatnot fence silliness as it, in fact, does currently
(unless I've just missed something) apart from data-dependent stuff
(because it doesn't do data-dependent reordering stuff like value
prediction which hardware can do).
regards,
alexander.