Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables
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.
... Work ....
... Work ...
This way deadlocks are impossible.
As this is sometimes not possible - we use deadlock detection in our
(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
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
Or hardcore: http://www.cs.rochester.edu/~scott/
More information about the fpc-devel