lock (mit?)

Az egyik cikk kommentjében merült fel egy lock-olással kapcsolatos kérdés. A kérdés előtt azonban nézzük meg az alapproblémát.

Ha van egy adatszerkezet/algoritmus, amely hajlamos inkonzisztens állapotot felvenni abban az esetben, ha több szál fut a kódon, akkor azokat egy “kerettel” védhetjük, amely keretet a lock kulcsszó (vagy a Monitor.Enter/Exit) jelöli ki.

Kezdetben kézenfekvő ötletnek tűnt, hogy szinkronizációs objektumnak magát a példányt használjuk, aminek a többszálúságra érzékeny kódját védeni szeretnénk:

class Stack
{
...
  void Push(T item) 
  {
    lock (this)
    {
      this.items[top++] = item;
    } 
  } 
}

Ilyet ma már eretnekség leírni, pedig az elv működik, bár bizonyos helyzetekben valóban veszélyes. Miért veszélyes? Nézzük a következő példát:

class Brother
{
   void BrotherThing(Sister sister)
   {
      lock (this)
      lock (sister)
      {
        ...
      } 
   }
}

class Sister
{
   void SisterThing(Brother brother)
   {
      lock (this)
      lock (brother)
      {
        ...
      }
   }
}

Igen, a kód erőltetett, mint általában a kicsi példakódok, de a lényeg érthető. Két objektumpéldány keresztbe használja egymást, mind a kettő szinkronizációt végez magán, illetve a használt példányon. Ha a BrotherThing és a SisterThing metódusok jó ütemben hívódnak, akkor a kód leáll. Első lépésben mind a BrotherThing, mind a SisterThing lockolja a saját példányát. Ezután szeretnék lockolni a másik példányt, amit viszont az előző pillanatban a másik szál lockolt, így mind a két szál futása beakad.

A fenti példában a fő gond nem az, hogy a this-en van a lock. A fő gond az, hogy ugyanazt a szinkronizációs objektumot (pl a Brother példányt) két különböző célra használjuk. Az egyik cél a példány belső állapotának konzisztensen tartása (ez a lock (this)), a másik pedig valami külső mechanizmus szinkronizálását szolgálja. Ez a két mechanizmus akad össze a példakódban.

A megoldást szinte mindenki ismeri, a belső konzisztencia védelmére nem szabad kívülről elérhető objektumot használni, így azzal nem lehet összeakadni sem:

class Brother
{
   private object sync = new object();

   public void BrotherThing(Sister sister)
   {
      lock (sync)
      lock (sister)
      {
        ...
      }
   }
}

class Sister
{
   private object sync = new object();

   public void SisterThing(Brother brother)
   {
      lock (sync)
      lock (brother)
      {
        ...
      }
   }
}

Cargo Cult programming

A gond az, hogy annyira elterjedt a külön célra létrehozott szinkronizációs objektum – akár okkal akár ok nélkül – hogy már csúnyának tűnik nem úgy csinálni. Az olvasót is ez a jelenség zavarta meg, és a kérdés úgy szólt, hogy miért nem jó ez a kód:

public void AddToList(List<int> list)
{
  lock (list)
  {
    list.Add(111);
  }
}

Ez a kód egyetlen dolog miatt tűnhet csúnyának – megszegi a privát szinkronizációs objektumra vonatkozó, tévesen kialakított ökölszabályt. Miről van szó a kódban? Tudjuk, hogy a List<T> nem szinkronizált, emiatt nem szabad több szálat ráengedni például az Add() metódusra. Ha van egy kódom, ami hívogatja az Add()-ot, biztosítanom kell, hogy ugyanarra a List<T> példányra ezt nem teszem meg több szálból. A fenti kódrész ezt megoldja.

Mikor lehet baj? Ha az List<T>.Add() valami olyan bonyolult dolgot végez, ami visszahat az én szinkronizációs rendszeremre. Nem árt óvatosnak lenni szinkronizáció esetében, de azért azt feltételezhetjük, hogy az Add() nem csinál ilyet. Az is problémát okozhat, ha más kódrészek valamilyen oknál fogva hosszú időre lockolják a lista példányt. Ekkor a mi kódunk akadályoztatva lesz, azonban nehéz lenne értelmes példát találni arra, hogy valaki a List példány-t lockolja, ugyanakkor más (például mi) egy másik szálon legálisan módosíthatná az állapotát.

Ökölszabályból baj nem lehet?

Baj talán nem, de teljesítményproblémák igen, ha vakon követem a “protokolt”. A fenti példában csinálhatok “szokás szerint” egy szinkronizációs objektumot, amely védi az AddToList kódját:

private object sync = new object();

public void AddToList(List<int> list)
{
  lock (sync)
  {
    list.Add(111);
  }
}

Ez most jobb? Hát nem éppen.. Ha több szálból hívodik az AddToList(), különböző List példányokkal, a hívások sorba lesznek állítva a lock-on, pedig semmi baj nem történne, ha párhuzamosan lefutnának. Az eredeti verzió nem szenved ettől a hibától, és helyesen csak az azonos példányra vonatkozó hívások állnak sorba.