This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [patch] Make std::tr1::shared_ptr thread-safe.

From: "Peter Dimov" <pdimov at mmltd dot net>
To: "Alexander Terekhov" <alexander dot terekhov at gmail dot com>
Cc: "Jonathan Wakely" <cow at compsoc dot man dot ac dot uk>,<libstdc++ at gcc dot gnu dot org>
Date: Tue, 29 Mar 2005 18:49:12 +0300
Subject: Re: [patch] Make std::tr1::shared_ptr thread-safe.
References: <OF51216141.374EAC91-ONC1256FD3.00537529-C1256FD3.005361E0@de.ibm.com> <e52efbe105032907371ce02f72@mail.gmail.com>

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. It just proves once again that non-label
notation for acquire/release (and others more relaxed
unidirectional) constraints sucks miserably. It's akin to
abuse of pthread_barrier_wait().

http://www.opengroup.org/austin/mailarchives/ag/msg07595.html
http://www.opengroup.org/austin/mailarchives/ag/msg07604.html
http://www.opengroup.org/austin/mailarchives/ag/msg07593.html

Just to clarify, when you say "won't work", do you mean that it is not guaranteed to work by POSIX, or that there is a platform, supported by libstdc++, where it doesn't work?

References:
- Re: [patch] Make std::tr1::shared_ptr thread-safe.
  - From: Alexander Terekhov

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]