New shared pointer - revision 2

[Koos Vriezen]

On Saturday 10 September 2005 16:24:22 Mirko Boehm wrote:
> I would like to state the obvious here: Since mit is a shared pointer, make 
> sure the class is thread-safe (which is not trivial). The reference counting 
> has to work acros thread boundaries.

Just curious, what is the cost of making this thread-safe? I'm asking
this because I wonder how often this will be used in such a way.

I'm always a bit sceptic when it comes to MT, IMO MT programs should
only exchange data between threads in critical sections. Other than
avoiding races, I can't really think of a real benefit as well. So one can
access a pointer thread safe, and then what, the pointer itself is not
thread safe. Oh wait, poll for a value to set by another thread? Come
on, we have pthread_cond_wait or pthread_join to do that much more
efficient.

I'm probably biased with all threading mess I've seen, I don't oppose
usage of thread, only treat them as separate programs and be very
explicit when exchanging data.

So if the overhead is significant, at least add a ST version too.

Koos