Kolejność synchronizowania według kolejności adresów w pamięci?

Jak wiadomo dead-locki (najczęstsze) powstają w następujacych sytacjach:

  • mamy dwa (conajmniej) obiekty synchronizujace S1, S2

  • wątek T1 zawłaszcza obiekty w kolejności S1, S2

  • wątek T2 zawłaszcza obiekty w kolejności S2, S1

  • oba wątki wykonują się w tym samym czasie

Jakiś czas temu wklejałem link do artykułu gdzie zalecano hierachię (globalną hierarchię) wszystkich sekcji krytycznych tak aby unikać dead-locków. http://www.ddj.com/hpc-high-performance-computing/204801163?pgno=3

Dziś znalazłem całkiem ciekawy sposób ustalania globalnej hierachii.

Można brać sekcje w kolejności rosnących fizycznych adresów w pamięci. :) Fajne, czyż nie?



I jeszcze trochę na temach hierarchii:

The most practical rule to avoid deadlock is to make sure that the locks are always acquired in the same order. In our example, it means that either the score or character lock must be acquired first—it doesn't matter which as long as we are consistent. This implies the need for a lock hierarchy—meaning that locks are not only protecting their individual items but are also keeping an order to the items. The score lock protects not only the values of the score, but the character lock as well.


I jeszcze troche na temat poziomów:

While lock leveling works, it does not come without challenges. Dynamic composition of software components can lead to unexpected runtime failures. If a low-level component holds a lock and makes a virtual method call against a user-supplied object, and that user object then attempts to acquire a lock at a higher level, a lock hierarchy-violation exception will be generated. A deadlock won't occur, but a run-time failure will. This is one reason that making virtual method calls while holding a lock is generally considered a bad practice. Although this is still better than running the risk of a deadlock, this is a primary reason databases do not employ this technique: they must enable entirely dynamic composition of user transactions.


I jeszcze trochę:

The easiest way to deal with this is to always lock the mutexes in the same order. This is especially easy if the order can be hard-coded, and some uses naturally lend themselves towards this choice. For example, if the mutexes protect objects with different roles, it is relatively easy to always lock the mutex protecting one set of data before locking the other one. In such a situation, Lock hierarchies can be used to enforce the ordering — with a lock hierarchy, a thread cannot acquire a lock on a mutex with a higher hierarchy level than any mutexes currently locked by that thread.

0 komentarze:

Prześlij komentarz

Tomasz Kulig