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

From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-06-30 17:38:23

[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. 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. Even if it is, I greatly
doubt that that approach is the right approach to achieve efficiency.
The common approach would be to worry about the right design first and
foremost, then run profilers/monitors/tests to see where we actually can
save memory/gain performance. Twisting design for the sake of perceived
performance/memory gains is often (I'd say always) a very bad idea.

Even if you do not buy into my arguments in the prev. paragraph, you'll
probably agree it'll be unfair to expect that the majority of library
users and overall general-purpose library design need to pay the price
of accommodating your very specific requirements. 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. 

...

[Christopher Currie]

Constructor parameters are, admittedly, a different discussion, and most

of them boil down to syntactic sugar for a non-locking constructor and a

call to some locking operation, blocking or otherwise. But (IMO) it's a 
useful syntactic sugar that *can* if used properly make programs less 
cumbersome to construct without sacrificing correctness or clarity.

[Batov, Vladimir] I am not against syntactic sugar if it is in line with
what is reasonably expected from a class. However, I am against
syntactic sugar which is not relevant to class functionality. Like I am
happy if I can simply give my credit card to a taxi driver and not worry
about having cash. However, I am not sure if I'd like that driver
singing. As far as S/W design is concerned, I'd prefer a taxi driver
class (with its responsibilities) and a singer class (with its
responsibilities). We all know how to blend those two classes if we ever
need that.