RE: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables
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 (MichaelScott), 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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel]Russianlocale information not compatible withFPClocale variables
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 [EMAIL PROTECTED] To: FPC developers' list fpc-devel@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 (MichaelScott), 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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables
Funny thing, we went trough the same evolution with our libraries over the years :-D . We used to have a single lock for each connection chain. Now we have individual locks for each component and each OpenWire pin, and it works much better and faster. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 3:23 AM Subject: Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables Come one, it's not that hard to understand :): synchronized might allow the same way of working: first, you work with big locks, later to add more fine granulated ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables
My personal experience so far has confirmed this. Reducing the scope and the duration of the locks, and allocating individual locks to individual resources increases the performance and oddly reduces the danger of deadlocks. I used to spend days tracking deadlock conditions. Hardly nowadays after allocating individual locks per critical resource, and carefully defining the scope of each lock. Having single centralized lock is hardly a good approach. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 3:23 AM Subject: Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables Come one, it's not that hard to understand :): synchronized might allow the same way of working: first, you work with big locks, later to add more fine granulated ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
