Multi threading support wasRe:[fpc-devel]Russianlocale informationnotcompatiblewithFPClocale variables

[Boian Mitov]

     Hi Helmut,

Thank you!
I agree with you.
I was just showing a case when the approach you ware describing is not 
applicable. I did not think you ware criticizing me or something ;-) . We 
both ware just showing approaches we use, and they both are very much 
classical one. I fell into the same pitfall as what they have. Unfortunately 
although we don't have any deadlocks at the moment, we are also thinking for 
some sort of automated deadlock resolution just in case. In our systems the 
developers can put the components in all kinds of configurations and expect 
them to work 24/7 (If they are in the Military or a TV broadcasting or in a 
Robot), and we are always afraid we may have overlooked some configuration 
where they will run into a deadlock. I agree however that while automatic 
resolution is a good thing to have if possible you must not rely on it, and 
mush have lock design that is not intended to produce deadlocks. The 
automatic resolution however is just a nice additional protection just in 
case things go wrong somehow.
Once again your points are 100% on the mark! I was just probably adding some 
small aspects to them ;-) .

  With best regards,
    Boian Mitov

--------------------------------------------------------------------
Mitov Software
http://www.mitov.com
--------------------------------------------------------------------


----- Original Message ----- 
From: "Helmut Hartl" <helmut.hartl at firmos.at>
To: "FPC developers' list" <fpc-devel at lists.freepascal.org>
Sent: Friday, August 01, 2008 12:36 AM
Subject: RE: Multi threading support wasRe:[fpc-devel]Russianlocale 
informationnotcompatiblewithFPClocale variables


Boian Mitov wrote:

> As you can see there are obvious scenarios where the granularity
> approach seems to be the only reasonable one.

I think you misunderstood me:
I wanted to say:

*) Maximum granularity gives maximum performance, but as always there is
a tradeoff.
*) Problems come in if you have DIFFERENT resources to lock and are not
able to maintain the right
   ORDER of locking, in the timeschedule.

Locks are well researched but yesterdays technology, and there is no
need to reinvent the wheel,
because there are exising published DEADLOCK Avoidance and DEADLOCK
Detection Algorithms available
for decades ... (Start here http://www.acm.org/sigs)
(So IMHO best would be to use existing and mathematical profen
strategies)

Please take a look at the papers at: http://www.cs.rochester.edu/~scott/

New directions are STM and Non Blocking Algorithms.

I want not to criticise, understand your design, nor i want to make it
better :-)
Just some state of the art research info - read it or ignore it - what
ever makes you happy ...

There are much smarter people then we are maybe, at least for me this
holds,
inventing new wheels ...

Greets,

 helmut

_______________________________________________
fpc-devel maillist  -  fpc-devel at lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel