.NET – lock
Az elmúlt héten a .NET szálkezelése kapcsán foglalkoztam picit a lock utasítással. Közismert, hogy az egymással versenyző szálak ugyanazon erőforráshoz való egyidejű hozzáférését valahogy meg kell akadályozni. Másképp mondva a folyamatot szálbiztossá (thread-safe) kell tenni akkor, amikor kritikus műveletet hajt végre. Elvégre egyidőben, pl. ugyanazt az objektumt (erőforrást) két különböző szálból tilos manipulálni, mert inkonzsztenciához vezethet.
Eme probléma egyik kivédési lehetősége a lock utasítás. Ebben még semmi különös nem lenne, de vajon tudja-e mindenki azt, hogy a lock mögött milyen másik .NET osztály működik? Talán igen, talán nem. Nézzük…
SajatOsztaly obj;
lock(obj) // Belép a kritikus területre
{
obj.CsinaljValamit();
} // Elhagyja a kritikus területet
A fenti lock hatására a SajatOsztaly obj példányának CsinaljValamit() metódushívása az adott szálon belül biztonságosan elvégezhető, hiszen abban az utasításblokkban védve van más szálak hozzáférése elől. Ez eddig nyilvánvaló. Az érdekesség inkább az, hogy a lock tulajdonképpen csak a fordítóprogram egy könnyítése azért, hogy a programozó kényelmesebben haladjon. Valójában a háttérben a .NET Monitor osztálya működik (a Monitor osztály a többi WaitHandle, Mutex, Semaphore, Interlocked, stb. szálaknál alkalmazható szinkronizáló osztályok közül az egyik).
SajatOsztaly obj;
Monior.Enter(obj); // Belép a kritikus területre
try
{
obj.CsinaljValamit();
}
finally
{
Monitor.Exit(obj); // Elhagyja a kritikus területet
}
A fenti Monitor osztály statikus metódusainak a hivása a try…finally kivételkezeléssel együtt ugyanaz, mint a korábban látot lock. Valójában a fordítóprogram a lock utasításból ilyen Monitor hívásokat generál. Hmm. Jó mi? Hát… nem is tudom. Remélem érthető volt, amit írtam.
“Windows 7” kérdések és válaszok
Kritika
Az OpenXML-nek nem az a baja, hogy Microsoft, hanem pl, hogy tartalmaz jelenleg is licenszdíj köteles megoldásokat…
A Microsoft egyébként egy rahedli jó dolgot tett le az asztalra. Rengeteg előremutató dolgot készítenek (pl TFS). Nem is ez a baj vele…
Leírok egy érdekességet (ez egy példatörténet ahhoz, amit mondani szeretnék):
A mai QWERTY billentyűzetnek azért pont ilyen a kiosztása, mert annó az írógépnek ilyen volt (és ehhez szoktak az emberek). Az írógépnek nem véletlenül lett QWERTY kiosztása. az első írógépeknek még ABC kiosztása volt, csak azon piszok gyorsan lehetet gépelni (gyorsabban, mint a QWERTY-n), ezért a kis betű-kalapácsok összeakadtak. Statisztikailag megvizsgálva a betűpárok gyakoriságát állították össze a QWERTY billentyűt. ennek az a tulajdonsága, hogy lassan lehet rajta gépelni! :) Ez így maradt az elektronikus korszakban is, egyszerűen mert az emberek hozzászoktak… (Létezik egyébként DVORAK billentyűzet, ami optimális ilyen szempontból, csak nem terjedt el).
Szóval 97%? :) Nem biztos, hogy azért mert az a legjobb… (Persze lehetséges ez a verzió is)… Igazából az, hogy 97% ezt használja, nem érv…"
Többszörös öröklődés C#-ban?
static void Main()
{
Musician bono = new Musician();bono.Use<Worker>().Name = "Bono";
bono.Use<Person>().Name = "Paul David Hewson";
bono.Use<Person>().Age = 47;
if (bono.Is<Musician>()) Console.WriteLine("{0} is musician.", bono.Use<Worker>().Name);
if (bono.Check<Person>()) Console.WriteLine("His age is {0}", bono.Use<Person>().Age);
}
Az EU szívózik a Microsofttal
[…]