Trey Jackson wrote: > All, > > (Note: I'm not critiquing the design choices, just trying to > understand the choices and the behavior of the implementation) > > I read in the docs that simultaneous reads are ok, but simultaneous > read/write or write/write are not. Ok, seems like a valid set up. > > When I looked at the implementation, it looks like the reference > counter uses a mutex when BOOST_HAS_THREADS is defined. > > Does that mean that if I have thread capability on my boost > installation (which I do), I pay for the mutex regardless of whether I > am actually using threads?
In a word, yes. The actual mutex being used depends on the platform. The overhead is usually acceptable, even with a plain pthread_mutex. > Secondly, if I'm paying for the cost of a mutex for the reference > count, why couldn't the shared_ptr also be protected by a mutex? > > Thereby making the simultaneous read/write safe (safe in that no > memory would be leaked b/c the pointers written/read). Consider this: // thread A p->f(); // thread B p.reset(); -- p->f(); is equivalent to p.operator->()->f(). To make the above work, operator-> would need to return a proxy that keeps the mutex locked. Even so, thread B may get there first. Even if you do if(p) p->f(); it is still possible for thread A to evaluate if(p) and thread B to intervene with a reset. And of course had this been (*p).f(); thread B can intervene between *p and the actuall call to f(), since there is no way to insert a locking proxy in operator*. In short, there is no way for shared_ptr to reliably synchronize your code for you. It is only responsible for synchronizing its own code. > Which brings me to a third question. > Let's say I've got a class (e.g. shared_count) that I sometimes want > to be protected by a mutex, and sometimes not. Say, for instance, I > want it to be protected by default, but sometimes I want to avoid that > overhead b/c I know I'll be using it in an environment that's already > protected by a mutex (and can avoid the extra mutex overhead). Can you demonstrate this with an example? > Question: is the following design a reasonable one? > It appears to work for me. > > template<class LockingStrategy> > class mySuperLockedClass : public LockingStrategy [...] Looks OK to me. > Just wondering if the above strategy could be used in the case of > shared_count, and if not, why not? Because of the extra LockingStrategy parameter. :-) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
