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: Paolo Carlini <pcarlini at suse dot de>
- To: Peter Dimov <pdimov at mmltd dot net>
- Cc: Phillip Jordan <phillip dot m dot jordan at gmail dot com>, libstdc++ at gcc dot gnu dot org
- Date: Thu, 06 Jul 2006 17:49:42 +0200
- Subject: Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety
- References: <44AD1E9B.4070801@gmail.com> <004401c6a111$5844d5e0$6701a8c0@pdimov>
Peter Dimov wrote:
The standard doesn't say anything about thread safety because in its
present form it has no notion of multiple threads, but tr1::shared_ptr
is intended to be thread safe. If the next standard is made
thread-aware - and this is very likely to happen - tr1::shared_ptr
will be described as offering the same level of thread safety as most
C++ types (multiple reads to the same instance OK, multiple writes to
distinct instances OK.)
Thanks Peter. Therefore, Philip, it seems to me that, given what we
currently have available from the compiler, a possible design would
involve a base class adding a three-valued template parameter and
defaulting to thread-safe and locks (atomics only when
_GLIBCXX_ATOMIC_BUILTINS).
The same class, would be also usable by itself, and the user would be
allowed to specify (for performance) thread-unsafe behavior or lockfree
via the additional template parameter.
Paolo.