--- In Boost-Users@y..., "Peter Dimov" <pdimov@m...> wrote:
From: "terekhov" <terekhov@d...>
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 <pthread.h> will someday become <cthread> and some future C++ <thread{*}> features (btw thread_shared_ptr does belong to them ;-) will be defined using "as if" term with respect to C <cthread> features PTHREADS/*C*THREADS (they just should not forget to destroy automatic C++ objects on cancel/exit raise some C++ cancel/exit exception ;-) regards, alexander.