Skip to main content

What are the base async patterns in .NET world

In momentul de fata exista diferite paternuri care sunt folosite pentru apeluri asyncrone. Am observat ca destul de multa lume incurca aceste paternuri si se face un mix intre acestea.
Din cate am observat pana acuma exista 3 paternuri principale care sunt folosite in general in .NET (mai putin 4.5, despre care o sa vorbim separat).
EAP (Event based Asynchronous Pattern) - in acest patern orice schimbare de stare (actiune se termina de executat, apare o eroare, progresul) sunt notificate prin intermediul unor evenimente.
public class FooEAP
{   
    public void CalculateAsync(int value1, int value2)
{
    int sum = value1 + value2;
    OnCalculateComplete(sum);
}
public event CalculateCompleteEventHandler CalculateComplete;
private void OnCalculateComplete(int result)
{
    if( CalculateComplete != null )
    {
        CalculateComplete(this, new FooCalculateEventArgs(result));
    }
}
}
APM (Asynchronous Programming Model) - paternul este destul de usor de recunoscut prin formatul BeginXXX si EndXXX. In momentul in care un utilizator apeleaza BeginXXX, task-ul incepe sa se execute. Aceasta metoda o sa returneze o implementare a interfetei IAsyncResult care are urmatoarea forma:
public interface IAsyncResult
{
WaitHandle AsyncWaitHandle { get; }
Boolean    IsCompleted     { get; }
Object     AsyncState      { get; }
Boolean    CompletedSynchronously { get; }
}
Aceasta interfata se poate folosii pentru a verifica in ce stare se afla actiunea noastra sau sa vedem progresul. Acest patern este destul de intalnit in WCF.
public class FooAPM
{
    IAsyncResult calculateAsyncResult;
    public IAsyncResult BeginCalculate(int value1, int value2)
{
    ...   
}
    public void EndInvoke()
{
    // Wait the task to finish
}
}
TPL (Task Parallel Library) - se bazeaza pe task-uri care au fost introduse cu .NET 4.0. Nu reprezinta un patern in sine, dar din .NET 4.5 mai ales o sa fim nevoiti sa le folosim din ce in ce mai des. In general acestea se foloseste cand lucram cu API care se bazeaza pe task-uri. TPL simplifica foarte mult paternul asyncron. Folosind TPL ne este mult mai usor sa scriem si sa folosim cod asyncron.
public class FooTPL
{
    public Task<int> Calculate(int value1, int value2)
{
    return new Task<int>(() => { return value1 + value2; });
}
}
Task-urile sunt destul de complexe din puct de vedere a API-ului. Sunt extrem de usor de folosit, dar trebuie folosite cu cap deoarece pot sa faca mai mult rau decat bine.
Odata cu .NET 4.5 au aparut async si await, iar orice apel poate sa fie executat asyncron fara sa mai scrim nici o linie de cod. In spate ele se bazeaza pe task-uri si fac parte din TPL si vin in ajutor programatorului. Folosinf aceste doua chei ne este multi mai usor sa scriem si sa facem apeluri asyncrone. In general aceste metode sunt denumite sub forma XXXAsync.
public class FooTPL
{
    public async Task<int> CalculateAsync(int value1, int value2)
{   
    int sum = await CalculateHelper.SumAsync(value1, value2);
return sum;
}
}
Despre cum functioneaza await, o sa revin intr-un post viitor.
Sper ca dupa citirea acestui post va este putin mai clar fiecare din aceste "paternuri". Toate fac acelasi lucru, doar ca in diferite moduri.

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP