[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-07-01 08:20:31

Batov, Vladimir wrote:

> [Christopher Currie]
> 
> In the need of extreme memory efficiency and speed: I already have, from
> 
> prior use, a scoped_try_lock 'l' around my mutex, currently unlocked. I 
> need to lock my mutex in a blocking fashion. I do not wish to pay the 
> memory and time cost to create an instance of scoped_lock just to do 
> this. I therefore call 'l.lock()' and not 'l.try_lock()'.
> 
> [Batov, Vladimir] I am sorry but I am far from being convinced that
> "extreme memory efficiency" can be achieved by saving on one lock.

One lock, called once, no; One lock created and destroyed repeatedly in 
a function that gets called thousands of times, possibly. I'll be the 
first to admit that I don't have any empirical evidence to support the 
scenario though, I simply tossed it out there as an example of why one 
might wish to have the operation supported. I work on a project where 
new designs are being considered that eliminate mutexes entirely because 
the performance penalty of locking them is too great.

> Locks
> are very transient creatures and created on the stack. Commonly the
> stack is predefined by OS regardless if you use it or not. Consequently,
> even when you do not create another object on the stack, that memory is
> not available to you for anything else anyway.

Does this hold true in embedded environments, where memory is at a premium?

> ... Twisting design for the sake of perceived
> performance/memory gains is often (I'd say always) a very bad idea.

I'd contest the assertion the design is (or is being) "twisted," simply 
different design decisions were made to serve differently perceived 
goals. There's nothing wrong with designing with performance as a goal.

> ...  For example, general
> memory allocation is often slow for me. Then, I write my own special
> memory allocator. I am not asking for the general-purpose allocator to
> be changed. 

A fair argument, although as designed, there is no facility to support 
writing my own special locking class; perhaps there should be. For 
example, say I'm writing a special queue class that supports separate 
locks for the enqueue and dequeue operations. Sometimes, I know that 
there is going to be only thread adding to the queue, so I'd like to 
specify that a dummy lock be used that doesn't actually lock the enqueue 
mutex. If there were a framework for a custom lock, I could support this.

I'm willing to run with the idea that try_locks and timed_locks don't 
need to have anything in common with basic locks. So, taking it further, 
do we then need to have lock() and unlock() operations at all? It 
enforces a usage paradigm: if you want to unlock your mutex, make sure 
the lock is deleted.

The only drawback is that, in the case of a try or timed lock, you 
wouldn't be able to try again on the same lock object, but perhaps this 
is a design advantage, forcing users to clearly define their critical 
sections. If you can't get your lock, fail out with an error.

-- 
Christopher Currie <codemonkey_at_[hidden]>