Multi threading support was Re: [fpc-devel]Russianlocale information not compatible withFPClocale variables

[Boian Mitov]

    Hi Helmut,

This is great for relatively simple system with number of shared objects.
In our case we have a graph of up to hundreds of objects and not all of them 
are connected (i.e. there are multiple independent graphs). The connections 
can be changed while the graphs are working, and all components can send 
data in any direction. and we need the components to do their job in 
separated threads. I have experimented with multiple approaches over the 
last 5 years, all the way up to this year we used a relatively small number 
of locks based on the chains in the graph. It never worked well until we 
finally switched to full granularity 3 months ago. For first time we see an 
very high throughput, and no deadlocks :-) . Simple strategies are great, 
and what you describe is what we usually do in relatively simple 
applications with limited threads and shared resources, but it is not 
universal solution, and unfortunately is not always applicable. Other 
solutions need to exist, to solve different scenarios.

  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: Thursday, July 31, 2008 11:06 PM
Subject: RE: Multi threading support was Re: [fpc-devel]Russianlocale 
information not compatible withFPClocale variables


Just some additional testing info and things to think about.

*) Performance of non granular locks is poor.
*) Creating 50K+ of lock instances makes the OS behave strange,
 so to fine granualer does not help either :-)

Simplest working Deadlock Avoidance strategys is:

Lock all resources at the same time in the same order.

Thread x
 LOCK A
  LOCK B
   LOCK C
 ... Work ....
   UNLOCK C
  UNLOCK B
 UNLOCK A

Thread x
 LOCK B
  LOCK C
   ... Work ...
  UNLOCK C
 UNLOCK B

This way deadlocks are impossible.

As this is sometimes not possible - we use deadlock detection in our
software.
(as classical database servers are doing it :-))

I describe it brief:

Everytime we lock in a thread we post a event to an non-blocking queue
(Michael&Scott),
similar on unlocking. The MS Queue is fast and does not block. At the
other side we
Detect the deadlocks by time (like a asynchrounous logger).
All our Locked operations are designed to take a small amount of
time (say some milliseconds). When we detect a nonpairing timedifference
of say one second, we found the deadlock and have to correct the code.

This is a debugging tool, wich does not save design time. But saves huge
amount of time
searching for deadlocks.

IMHO a full graph-theoretic cyclic redundancy check would be to much
waste of time - inefficient.

Another aproach would be STM. (software transactional memory).

For theory about locks:

Hector Garcia Molina, j.Ullman, J. Widom / DATABASE Systems the complete
Book.

Or hardcore: http://www.cs.rochester.edu/~scott/

Greets,

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