[boost] boost::shared_ptr<> locking strategies (was Re: Singleton)

From: Kevin Wheatley (hxpro_at_[hidden])
Date: 2005-01-12 05:56:32

Jody Hagins wrote:
> For example, if I have a multi-threaded application, Boost classes
> require me to use all multithreaded support.  However, my main thread
> may be tight, and use shared_ptr objects that do not span multiple
> threads.  In that case, I'd like to use something like shared_ptr< Foo,
> Noop_Lock_Policy > for stuff I know is OK without locking...

I have to agree with this. I've often wondered about something that
lives between a boost::scoped_* and a boost::shared_* along the lines
of what you suggest. Ideally I'd like something that can be promoted
to full shared status (reference counted and locking) at the thread
boundaries. But this could be dangerous obviously. I certainly think a
single threaded reference counted shared_* object would be useful even
within a multi threaded application if you know you have single thread
ownership.

For example, in a pipelined (1 thread per stage) process I'm passing
Data Transfer Objects along, which contain shared_ptr/shared_array
members that originally come from a aloocated 'pool' of resources
(memory buffers for instance). Once I'm inside a stage of my pipeline
"I'm" the owner so I don't need the locking, anymore.

Do others think this is sane?

Kevin

-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this      |
| Senior Technology                     | My employer for certain |
| And Network Systems Architect         | Not even myself         |