734
Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Uenal Mutlu
Date : Sat May 21 2005 02:59 pm

"Giancarlo Niccolai" wrote
> Maciej Sobczak wrote:
>
> > Uenal Mutlu wrote:
> >
> >>>The terminal?
> >>
> >> Of course:
> >> Question: Is in your application the terminal shared by multiple threads?
> >> Answer: YES
> >> Then: make the terminal lockable
> >
> > No. I have specifically used the puts() function to show you that there
> > are cases where there might be no "object" which you can "physically"
> > grab and wrap. This example was extremely simple, yet you have rejected
> > to see the point and have converted the example to use cout - just to
> > fit it to your broken idea?
> >
> > 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. If a terminal get
> disconnected while accessed, it may even be a kind of neverending
> operation. Cancelation problem apart (which Mutlu seems not to know as he
> speaks only about windows primitive), that may kill your thread while
> holding the terminal mutex, it is not correct to lock an OPERATION complex
> as a terminal output to secure the access to terminal OBJECT. Locking an
> operation (print) to protect an object (terminal) is wrong.
>
> You must find another way to output to the terminal in a way that won't be
> interfered by other threads. The way exists, and it's simple, just look a
> little further...
>
> The solution applies to all long operations applied to complex object, as
> database updates.

I don't know of what database you are talking, but maybe you can enlighten us.
So, just what is *your* solution to the problem?
Some pseudo-code will fully suffice. Let's know.

.

0