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

"Giancarlo Niccolai" wrote
> Uenal Mutlu wrote:
>
> > "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.
>
> Mine?
>
> To name few:
> - firebird/interbase
> - oracle
> - my-sql
> - postgresql
>
> The first two implement a transation registration system. The others a
> record level lock granularity, with a reflection on the database structure.
> Neither require the complete lock of the database for an update.

Sorry, that what you are talking about has not that much to do what we
are talking about. You seem to be a DB programmer. There things are
a little bit different, so what you wrote is IMO irrelevant to the underlying problem.

> Have a good book, please.

Yeah, you too.

.