Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Maciej Sobczak
Date : Thu May 19 2005 03:11 pm

Uenal Mutlu wrote:

>>It is neither simple (you limit yourself to use only the default
>>constructor of the given class)
> 
> That's an argument and I accept it. But OTOH IMO any class should
> have a default ctor, most STL classes (esp. the containers) are so.

Only because empty containers make sense. Not all classes have this 
"empty" state (I would even say that most of my classes don't) and if 
you want to make a rule out of it, you will end up with two-phase 
initialization of everything, which is completely contrary to what C++ 
is trying to promote. It is almost impossible to do right on the large 
scale. This does not belong to this group, however.

>>nor efficient (you have to lock a lot of
>>mutexes to achieve any non-trivial collaboration between separate objects).
> 
> If you see this in the context of multiple threads then IMO the approach is the
> most effective and fastest solution for the overall performance of the application.
> [...] if the data objects are independent of each other then it is
> more efficient to let each have its own mutex.

The fundamental problem is that you are trying to see your application 
as a loose bunch of low-level objects (strings, containers, etc.), which 
you think should be "thread-safe" in separation. What should be 
thread-safe, in fact, is the overall state of your program, not the 
state of each separate brick. The scope of this overall state is usually 
much broader than a single value object. Don't think in terms of 
"independent objects". If they were independent, you wouldn't put them 
all in the same program.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

.