Szálszinkronizáció

Többszálú programok főbb lehetséges problémái Versenyhelyzet („race condition”) A párhuzamosan futó szálak kommunikációjához szinte biztosan szükség van közös erőforrások (memória (közös változók), portok, I/O eszközök, fájlok) használatára Ha ezek állapotát egy szál módosítja, de közben más szálak is hozzájuk férnek, akkor az utóbbi szálak könnyen hibás vagy félkész adatokhoz juthatnak Holtpont („deadlock”) A szál olyan erőforrásra várakozik, ami sohasem érkezik meg Két vagy több szál egymásra várakozik (így egyik sem fejeződik be soha) Live lock occurs when threads continually conflict with each other and back off. 

Versenyhelyzet példák Szál 1 Szál2 Eredeti kód t = x x = t + 1 u = x x = u + 2 1. lehetséges kimenetel (x értéke 0) x = t + 1 (x értéke 1) x = u + 2 (x értéke 2) 2. lehetséges kimenetel 3. lehetséges kimenetel x = u + 2 (x értéke 3)

Versenyhelyzet Sok nyelvi konstrukció használatából is adódhat versenyhelyzethez vezető állapot! X++ A ++ az utasítások szintjén különálló olvasás és írás műveletből áll. (Memóriából kiolvasásig jut el „A” szál, amikor jön „B” szál és pl. elvégzi az X növelését. „A” szál számára azonban az X még a memóriából kiolvasott értéket viseli) X += 2 A += az utasítások szintjén különálló olvasás és írás műveletből áll. Mint előbb. A[i] += 1 Előfordulhat, hogy másik szál épp ugyanezen indexre dolgozna (esetleg más néven). Mint előbb. Természetesen magas szinten is létezik a probléma if (!list.Contains(key)) list.Add(key); A példák forrása: http://www.drdobbs.com/tools/avoiding-classic-threading-problems/231000499 Másik szál a két hívás lefutása között beillesztheti ugyanezt a kulcsot

Holtpont Oka (példából): Az osztály bármelyik tagjának használata előtt le kellett már egyszer futnia a statikus konstruktornak. A .NET egy belső lockkal biztosítja, hogy ez csak egyszer fusson le. A statikus konstruktor a háttérszálra vár (Join/Wait miatt)… … a háttérszál pedig a statikus konstruktor lefutására vár (a tagváltozó használata miatt). Klasszikus holtpont példa (kritikus szakasszal; magyarázat később): Erőforrásokat lockkal próbáltunk védeni. Mindkét szál már belépett az első kritikus szakaszba, ott viszont várakoznia kell, hogy hozzájusson a másik lehetséges erőforráshoz. lock (a) { // feldolgozás lock (b) } 1. szál 1 2 3 4 5 6 7 8 lock (b) { // feldolgozás lock (a) } 2. szál 1 2 3 4 5 6 7 8

Szinkronizáció kölcsönös kizárással Kritikus szakasz („critical section”) A programokon belül megjelölt kritikus kódrészletek soros végrehajtását biztosítja több párhuzamos szál esetén is. Amíg az egyik szál az „A” kritikus szakaszon dolgozik, a többi szál nem léphet be az „A” kritikus szakaszba. .NET osztályok: System.Threading.Monitor (és a C# „lock” utasítása), System.Threading.Mutex, System.Threading.ReaderWriterLock stb. Szemafor („semaphore”) A kritikus szakasz általánosítása (többpéldányos erőforrások esetén egyszerre több szál belépését is lehetővé teszi). .NET osztály: System.Threading.Semaphore Atomi végrehajtás („interlocked execution”) Egyes egyszerű műveletek oszthatatlan végrehajtását biztosítja (igen gyors). .NET osztály: System.Threading.Interlocked Csővezeték („pipe”), konkurrens gyűjtemények Olvasható és írható tároló, amely szükség szerint várakoztatja az igénylőket. (Az ún. „termelő-fogyasztó” probléma megoldására készült.) .NET-ben: System.Collections.Concurrent osztályai A lista nem teljes. Sztem ezen még pontosítani kéne.

Szinkronizáció bevárással (randevú) OE-NIK HP Szinkronizáció bevárással (randevú) Esemény („event”) Lehetőséget ad alkalmankénti vagy rendszeres jelzésre (pl: szál jelzi, hogy végzett a feladatával). .NET osztályok: System.Threading.AutoResetEvent, System.Threading.ManualResetEvent stb. Időzítő („timer”) Relatív vagy abszolút időhöz való igazodást tesz lehetővé. .NET osztályok: System.Windows.Forms.Timer, System.Timers.Timer, System.Threading.Timer stb. Event: Ez NEM a szokott .NET „esemény”-fogalom! Timerből már illene említeni a DispatcherTimer-t is, ezért inkább kivettem a táblázatot. Már a számok se biztos, hogy igazak azóta. Időzítők jellemzői Windows.Forms.Timer Timers.Timer Threading.Timer Pontosság ~10 ms ~100 ns (!) ~1 ms Futtatás saját szálon – + Csak egyszeri aktiválás Beállítható első aktiválás Vizuális komponens Platformfüggetlen

Lock lock (obj) { … } Ekvivalens: Monitor.Enter(obj), Monitor.Exit(obj) LockObject: szigorúan korlátozott hozzáférésű legyen a felesleges kizárások és a lehetséges holtpontok elkerülése miatt Legyen privát Lehetőleg példányszintű Ne legyen typeof(X), this, string…

Feladat Számoljuk meg, hány prímszám van 1 és 10 000 000 között! Az egyszerűség kedvéért az alábbi függvény segítségével döntsük el egy számról, hogy prím-e: static bool PrimSzamE(int szam) { if (szam <= 1) return false; if (szam <= 3) return true; for (int i = 2; i <= (int)Math.Sqrt(szam); i++) if (szam % i == 0) return false; return true; } Oldjuk meg a feladatot szekvenciálisan! Mennyi ideig tart? Oldjuk meg a feladatot Taskok segítségével! Alkalmazzuk a Parallel.For-t a megoldáshoz!

Feladat Készítsünk programot, amelyben 4 Task versenyez a konzolra íráson! Az egyes Taskok külön sorokba, különböző színnel írhatnak. Tipp: Console.SetCursorPosition(y, x); Console.ForegroundColor = c; Console.Write(s); Megjegyzés: a konzol ebben az esetben konkurrensen elért erőforrás, így a szinkronizációra ügyelni kell!