Re: Any interest in a weak pointer?

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-14 03:42:08

--- In Boost-Users_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "terekhov" <terekhov_at_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.