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

Helmut Hartl helmut.hartl at firmos.at
Fri Aug 1 08:06:09 CEST 2008


Florian Klaempfl wrote:
> Micha Nelissen schrieb:
>> Florian Klaempfl wrote:
>>> procedure p;synchronized mycriticialsection;
>>> 
>>> Any suggestions about doing it better?
>> 
>> How to avoid deadlocks?
> 
> Indeed, I'am open to any suggestions :) Just an idea: maybe a global
> call tree analysis with a call tree attributed with critical section
> information can find potential deadlocks?  

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



More information about the fpc-devel mailing list