Re: Fwd: memory

[Chris Vine <chris cvine freeserve co uk>]

On Friday 19 May 2006 06:45, Ramashish Baranwal wrote:
> Thats right. boost::shared_ptr<> is not designed to provide mutual
> exclusion. Its thread safe in the sense of maintaining its own
> integrity, i.e. you can safely use shared_ptr(s) in multiple threads
> to access the same underlying object. Its upto the underlying object
> to provide mutual exclusion (preventing simulataneous modification).
>
> > But you cannot safely modify a shared pointer (ie apply a
> > non-const operation to the shared pointer) in one thread and read from or
> > modify the same instance of shared pointer in another thread.
>
> shared_ptr is used to provide access to the underlying object, so you
> need not modify the "same instance of the shared_ptr" in another
> thread. Normally different threads used different instances of
> shared_ptrs all providing access to the same object. As a side note if
> you look closely even assignment of shared_ptrs modify their internals
> (reference count). But that is an implementation detail.
>
> > you cannot safely modify the referenced object in one thread and read or
> > modify it in another thread, unless the object does its own locking.)
> >
> > What this means is that you can have the same object referenced by a
> > container of shared pointers in one thread and a container of shared
> > pointers in another thread provided that you arrange separate locking of
> > the referenced object.  The circumstances in which you might want to do
> > that are quite limited.
>
> Not really. This cirumstance is in fact very common for single
> threaded applications, for applications which use their resources in
> only one thread, or for applications which serialize the modification
> of their resources to one thread. I see shared_ptr as a way of
> providing automatic memory management and not mutual exclusion. The
> cost of having locking for the underlying object in a shared_ptr would
> be prohibitive for applications that doesn't require it.

Your lengthy response deserves a slightly longer answer than may earlier one, 
now I have had my evening meal and watched the news on the TV!

I agree with what you wrote in general, but on your "so you need not modify 
the 'same instance of the shared_ptr' in another thread", the point is that 
in the particular multi-threaded use to which you refer it would be usual 
(and usually necessary) for a shared pointer intended for use in one thread 
(thread 1) to be used to initiase a shared pointer to the same referenced 
object in another thread (thread 2).  That is not thread safe if the first 
mentioned shared pointer might have a non-const operation carried out on it 
in thread 1 at or around the same time as it is used to intialise a pointer 
in thread 2, unless additional synchronisation is carried out.

On your last paragraph, you were in fact agreeing with me.  In each of the 
cases you mention ("single threaded applications, for applications which use 
their resources in only one thread, or for applications which serialize the 
modification of their resources to one thread") thread safety of the shared 
pointer is irrelevant.  I also agree that it is not desirable for a shared 
pointer to attempt also to lock the referenced object, although I gave you a 
link to a pointer implementation which does in fact do that and claims to do 
so efficiently.

This is probably becoming a bit off topic, having derived from my remark that 
"thread safe" has a number of different meanings, with which I think we both 
agree.

Chris