Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Sat May 21 2005 05:18 pm

Maciej Sobczak wrote:

> Giancarlo Niccolai wrote:
> 
>>>Let's say there is no cout, but instead the "print" function:
>>>
>>>print("I'm doing something");
>> 
>> More. The terminal operation may be a LONG operation.
> 
> It is not the point here. The point is that synchronizing threads is not

Yes in fact ...

> 
> If you are concerned about this possibility, then that's fine -
> depending on your environment. Others might be concerned about
> spontaneously disconnecting hard drives or even CPUs (you may not
> believe, but I remember having disconnected hard drive whereas I do not
> remember any disconnected terminal).
> 
> It was not the focus of this example, however.

.... I wasn't adversing you. I just showed another reason why locking
operations is a bad idea. It's a "moreover", not a correction.

> 
>> Locking an
>> operation (print) to protect an object (terminal) is wrong.
> 
> In this example, it is not the terminal (as a physical object) which was
> protected, but rather the "continuity" of the information that is printed.
> 
>> You must find another way [...] The way exists, and it's simple, just
>> look a little further...
> 
> If you are talking about "transactions", then no. No matter what (and
> how much effort you want to put into it), sooner or later you will have
> to call this print function and if done from many threads, the problem
> is still there.

No, I am talking about i.e. queuing print requests and have a specialized
thread to handle them. And that is just one of the possible approaches.


> If you are talking about having a separate thread (or even process) that
> will be responsible for printing, then here also the problem is still
> there, just moved from one place to another.

Uhm, yes, if you are not careful. I.e. if your problem is just to print a
single unit of data coherently ( i.e. a log line), this approach is good.
If your problem is that of having multiple units of data coherently
printed, then you need another approach, as i.e. passing to the printer
thread the whole set of units when it's ready to be printed in one atomic
operation, or declaring that set ready in one precise moment...

Yet many other approaches are possible, as i.e. printing in each thread and
setting a (mutexed) flag to prevent other threads to print in the
meanwhile; if a thread willing to print finds the resource busy, it may 1)
do something else and try again later or 2) sync on a condition variable if
it knows it has nothing to do in the meantime or even 3) wait on multiple
condition and resume to do processing or print, whichever comes ready
first. IMHO this is one of the most flexible and elegant one.


> 
> Anyway - it was not the point of this example.
> 

Yes: when I start a reply with "MORE" I really mean "and, aside/given this,
there's more". Sorry if I didn't make it clean from the start ;-), I really
agree with all you said.

Giancarlo.

.