--- In Boost-Users@y..., "Peter Dimov"
From: "terekhov"
On the other hand placing a memory barrier in shared_ptr will probably be a good thing from user point of view;
I think so too, but how about portability... also, given rather close to NULL amount of interest (wrt the proposal for having portable interface specifically for ref.counting) I've observed on c.p.t, I am not sure at all... maybe I am missing something subtle and the whole idea of a single "RMB" might be a BS... I do not know, really.
Perhaps C++ compilers already do the right thing on "delete p", i.e. synchronize. They need to do that anyway to protect the allocator.
That is unlikely, I think. For example, consider that in PTHREAD memory model: "Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Such access is restricted using functions that synchronize thread execution and also synchronize memory with respect to other threads. The following functions synchronize memory with respect to other threads: ... Applications may allow more than one thread of control to read a memory location simultaneously." It is just impossible to build correct smart_ptr that would require you to synchronize "in the destructors", even if threads unref() mutable shared objects INSIDE their synchronized regions, before "unlock" (I mean sync.regions where mutable shared objects become modified). That is just yet another reason why I dislike the idea of "synchronized destructors".
but I don't want to make shared_ptr depend on pthreads.
Yeah, pthreads is not a boost library, but other than that argument and perhaps some licensing issues wrt LGPL nature of pthreads-win32, I do not see why boosters just ignore pthreads. It is a standard and it is available on almost every platform out there (I mean basic threading stuff).
pthreads is fine, it's just that the current smart_ptr.hpp doesn't need pthreads and I wanted to stay backward compatible.
Two points:
- I think that you still might want to provide a pure
single-treaded version of your smart_ptr. It would
be useful for pure single-threaded programs and
for thread-private "shared" objects in multi-
threaded programs. How about shared_ptr and
thread_shared_ptr (you might also want to provide
an optimized version for const shared objects
without any memory sync)? BTW, it seems that
currently you need TWO mutexes per counted_base
for the PTHREAD version. Races aside, I think
that it is really too many...
- with "do not ignore PTHREADS" I just wanted to
encourage you to write your code on top of PTHREAD
opaque objects (pthread_mutex_t), their methods
in C notation (pthread_mutex_lock) and their
return codes ONLY. Just pretend that PTHREADS
being the standard extension to ANSI C is
available universally. Now, but what about WIN32
and users who just do not want to download pthread-
win32 LGPL library, for example? NO PROBLEM.
Just include your own mini-pthreads-win32 impl
in your own distribution package. The same goes
for any other platform you might want to support
and which does not natively have PTHREADS on it.
To me, it is just like some home grown C++ file
streams on top of standard C fopen/fread/fwrite/etc,
or in other words, just imagine that