Use lock in a block that contains a call to an async method (await keyword)

Citeam urmatorul post http://qedcode.com/content/awaitable-critical-section, in care se explica o modalitate de a face lock in cazul in care in block-ul de lock contine un apel la o metoda async.
Pe scurt, pentru a evita ca doua sau mai multe thread-uri sa scrie simultan in acelasi fisier, se incerca sa se faca lock. Dar .NET 4.5 nu ne lasa sa avem urmatorul cod (si foarte bine face):

lock( this )
{
    var f = await storageFile.OpenAsync();
    ...
    await file.WriteAsync("some content");
}   

Eroarea pe care o primim arata in felul urmator:

The 'await' operator cannot be used in the body of a lock statement.

In link-ul pe care l-am dat mai sus, s-a incercat implementarea unei solutii custom care face lock la o anumita portiune de cod. O alta varianta ar putea sa fie sa incerca sa folosim Task.Run. Cea ce am obtine ar fi ceva asemanator cu urmatorul cod

lock( this )
{
    var f = await storageFile.OpenAsync();
    ...
    Task.Run(async () => {await f.WriteAsync("some content") }).Wait();
} 

Codul s-ar compila fara nici o problema dar la rulare am vedea ca aplicatia nu mai raspunde cand ajunge pe linia de cod care contine Task.Run. Din aceasta cauza se poate ajunge sa implementam ceva asemanator cu link-ul dat la inceputul postului.
Cea ce nu imi place la nici o solutie este ca combinatia dintre lock si async nu suna foarte bine. De ce ai vrea sa faci un lock si sa te asiguri ca doar un singur apel asyncron se executa. De foarte multe ori problema poate sa fie de design. Nu degeaba .NET nu iti permite aceasta funcționalitate.
Un await in interiorul unui lock poate sa genereze foarte usor un deadlock. Problema este destul de asemanatoare cu deadlock-ul care se obtinea cand apelam Monitor.Exit in interiorul unui ExisDisposable.Dispose.
Cand se face resume la cod in general ajungem pe acelasi thread, dar acest lucru nu e obligatoriu, din aceasta cauza putem sa ajungem pe un alt thread, care ar face unlock la un lock facut pe un alt thread.
Be aware, cand folositi await, nimeni nu va garanteaza ca la resume o sa ajungeti pe acelasi thread. Trebuie sa mai tinem cont de inca un lucru, o metoda la care facem await nu stim cat o dureze, iar un lock ar trebui sa fie facut pentru o perioada cat mai mica de timp. Pentru acest lucru putem sa facem lock pe codul pe care il executam inainte si dupa apelul la metoda await.
Codul pe care l-am obtine ar avea urmatoare forma:

var f = await storageFile.OpenAsync();
lock(this)
{   
    ...
}
await f.WriteAsync("some content");
lock(this)
{
    ...
}

Da stiu, se doreste ca metoda WriteAsync sa fie executa intr-un lock. Dar acest lucru nu e sanatos. Daca vrem doar noi sa avem drept de scriere, atunci trebuie sa deschide fisierul in asa fel incat doar dintr-un singur loc sa se poata scrie. Pentru a putea face acest lucru este nevoie sa specificam ca parametru la metoda OpenAsync FileAccessMode.

var f = await storageFile.OpenAsync(File.AccessMode.ReadWriteNoCopyOnWrite);
sau (in functie de caz)
var f = await storageFile.OpenAsync(File.AccessMode.ReadWrite);

In concluzie, cand ajungeti la un caz cand aveti nevoie de a face lock pe un block de cod care contine apeluri de metode asincrone, ar fi bine sa faceti un review la cod si sa vedeti daca chiar aveti nevoie de asa ceva si daca nu este o greseala in design-ul aplicatiei.

Read More

AppFabric Cache - more than one writers in the same time

Intr-un post anterior am discutat despre AppFabric Cache, care are la baza mecanismul de DataCache pentru Windows Cache Server. Intr-un mediu in care avem mai multe masini care scriu pe acelasi cache trebuie avuta grija destul de mare la urmatorul caz:

In acelasi timp 2 sau mai multe masini doresc sa scrie acelasi element in cache( aceiasi cheie).

Cuvantul cheie la aceasta problema este "IN ACELASI TIMP". In mod normal am avea urmatoarea implementare pentru a scrie un obiect in cache:

DataCacheFactory cache = new DataCacheFactory();

cache.Put(key,value);

Totul ar functiona fara nici o problema pana cand 2 sau mai multe instante ar incerca sa scrie in acelasi timp un element cu aceiasi key in cache. In acest caz se arunca o exceptie de tip DataCacheException, cu error codul setat DataCacheErrorCode.RetryLater.
Pentru a rezolva aceasta problema avem doua solutii, in functie de cat de probabil e sa apara un astfel de caz putem sa folosim una din solutii, sau o combinatie din cele doua.
Prima solutie ar fi sa me folosim de mecanismul de lock care exista pentru cache.

DataCacheLockHandle lockHandle;

var value = cache.GetAndLock(key, TimeSpan.FromSeconds(1), out lockHandle, true);

cache.PutAndUnlock(key, value, lockHandle);

Avantajul la aceasta solutie este ca inainte sa se faca scrierea se face un lock explicit pe obiectul din cache, dar trebuie avut grija ca fiecare aplicatie care foloseste cache-ul sa foloseasca metode care fac lock - in caz contrat obiectul poate sa fie accesat chiar daca s-a facut lock pe acesta. Un alt dezantaj la aceasta solutie este ca trebuie facute doua requesturi la server. Unul care face GET si altul care face PUT si totodata in cazul in care se intampla ceva intre GET si PUT obiectul din cache poate sa ramana blocat din cauza lock-ului pe care il facem( trebuie sa ne implementam un mecanism de fallback.
Urmatoarea solutie pe care o propun este mult mai primitiva, dar care conserva atat conexiunea la internet cat si durata cat timp obiectul este blocat.

int retrys=5;
while(true)
{
     try
     {
          cache.Put(key,value)
     }
     catch(DataCacheException ex)
     {
          if(ex.ErrorCode == DataCacheErrorCode.Retrylater)
          {
               if(retrys <= 0)

               {

                     throw;

               }

               retrys--;

               continue;
          }

          throw;

     }
}

In cazul in care acest caz nu o sa apara foarte des as alege a doua varianta. Este mult mai simpla si mai sigura. Cand folosim a doua varianta trebuie sa avem grija daca exista si alte aplicatii care acceseaza cache-ul nostru - toti consumatorii trebuie sa foloseasca mecanismul de lock, deoarece altfel nu ar avea nici o valoare modul in care scrim noi in cache.

Read More

How to lock a method - synchronized

Nu odată mi s-a întîmplat sa am nevoie sa sincronizez una sau mai multe metode din aceiași clasa.
In funcție de situație foloseam un cod asemănător cu cel de mai jos:

class ItemsStore
{
   void AddItem(Item item)
   {
       lock(this)
       {
           ...
       }
   }
 
   void RemoveItem(Item item)
   {
       lock(this)
       {
           ...
       }
   }
 
   Item[] GetAvailableItemes()
   {
       lock(this)
       {
           ...
       }
   }
}

Sunt cazuri când lock-ul se face pe un field sau pe un obiect diferit de this dintr-o alta clasa. Unu din dezavantaje care apare în acest caz este apariția a unui nou nivel de indentare.
Am descoperit un alt mecanism prin care se poate face lock automat pe metodele dorite. Deși exista din .NET 1.1 și cea mai mare parte din voi l-ați folosit deja, am considerat ca merita amintit.
Prin intermediul atributului MethodImpl putem specifica modul în care sa se facă lock-ul pentru fiecare metoda în parte( nu mai este nevoie sa folosim lock sau SyncLock) și nu numai. Prin acest atribut putem de fapt sa specificam de fapt modul în care o metoda se implementează.
Codul scris mai sus îl putem rescrie în forma următoare:

class ItemsStore
{
   [MethodImpl(MethodImplOptions.Synchronized)]
   void AddItem(Item item) { ... }
 
   [MethodImpl(MethodImplOptions.Synchronized)]
   void RemoveItem(Item item)    { ... }
 
   [MethodImpl(MethodImplOptions.Synchronized)]
   Item[] GetAvailableItemes()    { ...  }
}

Personal cred ca în felul acesta codul devine mai ușor de înțeles si mai clar. Cea ce trebuie avut grija este ca MethodImplOptions.Synchronized face lock pe obiect și nu în toate cazurile avem nevoie de acest lucru.
Enumul MethodImplOptions ne permite sa setam următoarele stări pe care le putem combina:

• Unmanaged - Specifies that the method is implemented in unmanaged code.
• ForwardRef - Specifies that the method is declared, but its implementation is provided elsewhere.
• PreserveSig - Specifies that the method signature is exported exactly as declared.
• InternalCall - Specifies an internal call. An internal call is a call to a method that is implemented within the common language runtime itself.
• Synchronized - Specifies that the method can be executed by only one thread at a time. Static methods lock on the type, whereas instance methods lock on the instance. Only one thread can execute in any of the instance functions, and only one thread can execute in any of a class's static functions.
• NoInlining - Specifies that the method cannot be inlined.
• NoOptimization - Specifies that the method is not optimized by the just-in-time (JIT) compiler or by native code generation (see Ngen.exe) when debugging possible code generation problems.

Sursa: http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx

Enjoy it.

Read More