Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Sergei Organov
Date : Thu May 19 2005 03:36 pm

"Uenal Mutlu" <520001085531-0001@t-online.de> writes:
> "Sergei Organov" wrote
[...]
> Hmm. so you are using just one mutex for the whole class (for all
> shared data objects). 

Does it *actually* matter? I don't see anything in your "problem
description" that suggests it is. On the other hand, my solution has
much less operations on mutex than your one.

> This is not the recommended way because you are blocking too much and
> too long.

Why didn't you specify this as one of requirements in your "problem
description" then? Instead you chose to clutter your challenge with a
lot of information unrelated to the problem.

> Imagine if inside f2() the mutex is locked, then no other thread can
> do anything else; all have to wait for f2() release the mutex. By
> using just one mutex you effectively made the program practically
> "single-threaded". IMO this approach is far from being efficient. Why
> not use 3 mutices?...

The question is in fact an opposite: why use more than 1 mutex? From
your "problem description" it's impossible to draw any reasonable
conclusion on pros and cons of two solutions, so the only rule that
definitely applies is: "the simpler, -- the better", or, abbreviated,
KISS ;)

> > > Why would you remove f2() since it is a member function, ie. an API
> > > function.
> >
> > 1. Because f2() is not a good name for an API function, obviously.
> 
> Understand.
> 
> > 2. Because the API probably is broken to the same level as the rest of
> >    the design.
> 
> The API is just the public functions of the class, so we can say
> that the naming f1(), f2(), .., f9() is a bad choice, and that instead we
> should have taken some better names. I agree. Thank you very much.

Well, in (2) I meant something different. An API function has some
semantics that will probably won't be there anymore after redesign.
I.e., the API will probably be changed so dramatically that it will be
difficult to find in the new API a function that is an analog of your
f2(), whatever undisclosed semantics it has.

-- 
Sergei.

.