[boost] shared_ptr question (with respect to thread safety)

From: Trey Jackson (tjackson_at_[hidden])
Date: 2003-02-05 13:09:48

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?

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).

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).

Question: is the following design a reasonable one?
It appears to work for me.

template<class LockingStrategy>
class mySuperLockedClass : public LockingStrategy
{
public:
  void read() 
  {
    LockingStrategy::readlock();
    // do stuff
  }
  void write() 
  {
    LockingStrategy::writelock();
    // do stuff
  }
};

struct
EmptyLockingStrategy 
{
  void readlock() 
  {
    // Just a no-op
  }
  void writelock() 
  {
    // Just a no-op
  }
  
};

struct
MutexLockingStrategy 
{
  boost::mutex m_;
  void readlock() 
  {
    boost::mutex::scoped_lock l(m_);
  }
  void writelock() 
  {
    boost::mutex::scoped_lock l(m_);
  }
};

struct
ReaderWriterLockingStrategy 
{
  boost::unimplemented::rwmutex m_;
  void readlock() 
  {
    boost::unimplemented::rwmutex::scoped_read_lock l(m_);
  }
  void writelock() 
  {
    boost::unimplemented::rwmutex::scoped_write_lock l(m_);
  }
};

Just wondering if the above strategy could be used in the case of
shared_count, and if not, why not?

thanks,

TJ

-- 
Trey Jackson
tjackson_at_[hidden]
"A life lived in fear is a life half lived."
-- No Fear