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

Uenal Mutlu wrote:

> "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.

I am not just a db programmer. And it's not me that suggested to lock a
database representation object instance in the first place, but you.

> 
>> Have a good book, please.
> 
> Yeah, you too.

I usually write them. But I read a lot of them before.

Bests,
Giancarlo.

.