async await c# aantal vragen waar ik niet uit kom

[HawVer]

Ik ben begonnen met asynchroon maken van mijn ASP .NET Web Api vanuit de gedachte dat mijn server straks meer verzoeken tegelijkertijd kan afhandelen. Ik ben begonnen met het doorlezen van het boek "Async in C# 5.0". Daarnaast is er een aantal artikelen die ik doorgelezen heb. Er is nog een aantal dingen die niet helemaal duidelijk zijn.

Op een gegeven moment komt mijn programma uit bij de await aanroep. De code die ik daarmee aanroep wordt in een andere thread uitgevoerd.

Vraag 1: kan ik vanuit de code die asynchroon wordt uitgevoerd een functie aanroep die niet de async modifier bevat? Wordt dan de aanroepende code ook synchroon uitgevoerd? Bijvoorbeeld

C#:

public async Task<int> ExampleMethodAsync()  
{  
    Method();
} 

public void Method()
{
 // 
}

Vraag 2: Hoe vaak kom je problemen tegen in code die async await wordt uitgevoerd en die ontstaan zijn door multithreading problematiek. Overal lees je in artikelen over race conditions en deadlock problemen die erg moeilijk zijn op te lossen. Maar ik kom erg weinig artikelen tegen die vertellen hoe je deze problemen kan voorkomen. Ik ben dus niet op zoek naar hoe een mutex, locks en semaphores werken, maar ik ben op zoek naar
a.. moet ik ze uberhaupt inzetten bij async await?
b.. hoe kan ik zoveel mogelijk voorkomen dat ik ze nodig heb? Ik lees iets over "less stateful code" en "referential transparancy", maar dat zijn maar twee zinnen. Googlen op die termen levert niet veel bruikbaars op.
c.. wanneer moet ik ze inzetten? Moet ik per definitie alles wat ik schrijf naar een variabele locken?

Enige hulp bij deze vragen zou zeer welkom zijn.

[whoami]

Met de async modifier geef je enkel aan dat er in die method een awaitable kan aangeroepen worden.
Die async method wordt gewoon synchroon aangeroepen tot wanneer er op de await gebotst wordt. Daar wordt er eigenlijk aangegeven dat er een Task moet uitgevoerd worden (promise)

Het await keyword in C# zorgt er eigenlijk voor dat alles wat na het 'await' keyword komt binnen die async method pas uitgevoerd wordt, als die Task waarop 'ge-await' wordt, uitgevoerd werd, zonder de huidige thread te blocken. Die Task wordt asynchroon uitgevoerd.

Als je dus geen awaitables hebt in een async method, dan zal die method gewoon synchroon uitgevoerd worden, en dat zal de C# compiler ook aangeven dmv een warning indien je jouw code voorbeeld compileert.

Async/Await gebruik je typisch bij I/O operaties. Je zal bv zien dat vrijwel alle bestaande I/O operaties in .NET (lezen / schrijven naar een file, naar een stream, etc...) een 'async' variant hebben.

Lock's & Mutexen heb je op zich enkel nodig als je shared state hebt tussen verschillende threads.

De deadlock issues waar je over gelezen hebt, hebben meestal te maken met het feit dat er geen correct gebruik gemaakt wordt van async / await. Dat is hier en hier goed uitgelegd.

[ Voor 17% gewijzigd door whoami op 19-10-2017 23:09 ]

[HawVer]

whoami schreef op donderdag 19 oktober 2017 @ 22:46:
Met de async modifier geef je enkel aan dat er in die method een awaitable kan aangeroepen worden.
Die async method wordt gewoon synchroon aangeroepen tot wanneer er op de await gebotst wordt. Daar wordt er eigenlijk aangegeven dat er een Task moet uitgevoerd worden (promise)

Het await keyword in C# zorgt er eigenlijk voor dat alles wat na het 'await' keyword komt binnen die async method pas uitgevoerd wordt, als die Task waarop 'ge-await' wordt, uitgevoerd werd, zonder de huidige thread te blocken. Die Task wordt asynchroon uitgevoerd.

Als je dus geen awaitables hebt in een async method, dan zal die method gewoon synchroon uitgevoerd worden, en dat zal de C# compiler ook aangeven dmv een warning indien je jouw code voorbeeld compileert.

Bedankt voor je antwoord. Ik bedoelde eigenlijk deze situatie. Dus het is een mix van asynchrone en synchrone code. Zie code voorbeeld. Stel ik begin onderin in één van de uiterste hoeken van mijn code, moet ik dan de code tot bovenaan toe alle en alles wat ik aanroep async maken? Moet mijn volledig web api async zijn of geldt dat alleen voor de code die gebruik maakt van IO, bijvoorbeeld database...

code:

public async Task<int> ExampleMethodAsync()  
{  
    await Method1();
    Method2();
} 

public void Method()
{

}

Async/Await gebruik je typisch bij I/O operaties. Je zal bv zien dat vrijwel alle bestaande I/O operaties in .NET (lezen / schrijven naar een file, naar een stream, etc...) een 'async' variant hebben.

Heeft het dan wel zin om mijn asp.net web api volledig async te maken? Of zou dat dan alleen nodig zijn voor de aanroepen naar de database?

Lock's & Mutexen heb je op zich enkel nodig als je shared state hebt tussen verschillende threads.

Ik heb een stukje code geschreven bovenop ADO.NET. Daarin geef je een abstract syntax tree van een query mee en maakt er dan afhankelijk van welke database je gebruikt nette sql string van. De root van de tree wordt opgeslagen in een class querycommand. Je zou de querycommand meerdere keren paralel uit kunnen voeren. Betekent dit nu dat de root van de tree shared state is en dat ik daar dan dus een lock voor moet gebruiken? Hij wordt alleen in de constructor gevuld en is daarna een readonly waarde.

De deadlock issues waar je over gelezen hebt, hebben meestal te maken met het feit dat er geen correct gebruik gemaakt wordt van async / await. Dat is hier en hier goed uitgelegd.

Die issues heb ik inderdaad voorbij zien komen. Dus de deadlock zou buiten deze issues geen probleem moeten zijn. Ik ben bang dat ik straks al mijn code async heb gemaakt en dat als het live draait en meerdere clients tegelijk beginnen te tetteren dat hij dan vol lastige bugs zit.

[whoami]

HawVer schreef op vrijdag 20 oktober 2017 @ 08:10:
[...]

Bedankt voor je antwoord. Ik bedoelde eigenlijk deze situatie. Dus het is een mix van asynchrone en synchrone code. Zie code voorbeeld. Stel ik begin onderin in één van de uiterste hoeken van mijn code, moet ik dan de code tot bovenaan toe alle en alles wat ik aanroep async maken? Moet mijn volledig web api async zijn of geldt dat alleen voor de code die gebruik maakt van IO, bijvoorbeeld database...

code:

public async Task<int> ExampleMethodAsync()  
{  
    await Method1();
    Method2();
} 

public void Method()
{

}

Is de method 'Method' in bovenstaand codevoorbeeld eigenlijk Method1 die je aanroept in de method daarboven ?
In dat geval kan je op Method1 niet awaiten, want die is niet async en returned geen Task.

Heeft het dan wel zin om mijn asp.net web api volledig async te maken? Of zou dat dan alleen nodig zijn voor de aanroepen naar de database?

De stukken waar je I/O doet zou ik zeker async proberen te maken. (schrijven naar filesystem, naar network, naar db).
Ik zou beginnen met overal waar je reeds bestaande 'async' methods kunt oproepen, deze gebruiken. Dit zal er toe leiden dat bepaalde van jouw web-methods async zullen worden.

Voor de rest is het moeilijk daar veel uitspraken over te doen aangezien ik niet weet wat jouw API eigenlijk doet.

[ard1998]

HawVer schreef op donderdag 19 oktober 2017 @ 22:21:
Ik ben begonnen met asynchroon maken van mijn ASP .NET Web Api vanuit de gedachte dat mijn server straks meer verzoeken tegelijkertijd kan afhandelen. Ik ben begonnen met het doorlezen van het boek "Async in C# 5.0". Daarnaast is er een aantal artikelen die ik doorgelezen heb. Er is nog een aantal dingen die niet helemaal duidelijk zijn.

Op een gegeven moment komt mijn programma uit bij de await aanroep. De code die ik daarmee aanroep wordt in een andere thread uitgevoerd.

Vraag 1: kan ik vanuit de code die asynchroon wordt uitgevoerd een functie aanroep die niet de async modifier bevat? Wordt dan de aanroepende code ook synchroon uitgevoerd? Bijvoorbeeld

C#:

public async Task<int> ExampleMethodAsync()  
{  
    Method();
} 

public void Method()
{
 // 
}

Volgens mij moet je een instantie van een object maken waar de desbetreffende async task<> in zit om zo vanuit een statische methode de async task aan te roepen. (toevallig was ik dit laatst aan het leren voor mijn mijcrosoft certificaat c# programming)

ik heb een klein voorbeeldprogramma voor je geschreven om dit te visualiseren

C#: program.cs

 
using System;

namespace TEST
{
    class Program
    {
        static void Main(string[] args)
        {
            var test = new async();
            double ret = test.test().Result;
            Console.WriteLine(ret + " seconden");
            Console.ReadLine();
        }
    }
}

 

C#: async.cs

 
using System;
using System.Threading.Tasks;

namespace TEST
{
    class async
    {
        public async Task<double> test()
        {
            int timeWait = new Random().Next(1000, 10000);
            await Task.Delay(timeWait);
            return (double)timeWait/1000;
        }
    }
}

HawVer schreef op donderdag 19 oktober 2017 @ 22:21:
Vraag 2: Hoe vaak kom je problemen tegen in code die async await wordt uitgevoerd en die ontstaan zijn door multithreading problematiek. Overal lees je in artikelen over race conditions en deadlock problemen die erg moeilijk zijn op te lossen. Maar ik kom erg weinig artikelen tegen die vertellen hoe je deze problemen kan voorkomen. Ik ben dus niet op zoek naar hoe een mutex, locks en semaphores werken, maar ik ben op zoek naar
a.. moet ik ze uberhaupt inzetten bij async await?
b.. hoe kan ik zoveel mogelijk voorkomen dat ik ze nodig heb? Ik lees iets over "less stateful code" en "referential transparancy", maar dat zijn maar twee zinnen. Googlen op die termen levert niet veel bruikbaars op.
c.. wanneer moet ik ze inzetten? Moet ik per definitie alles wat ik schrijf naar een variabele locken?

Enige hulp bij deze vragen zou zeer welkom zijn.

2 Door goed gebruik te maken van de thread namespace en het lock statement zullen problem niet vaak voorkomen. zelf heb ik nog geen problemen meegemaakt met async dingen, het kost aleen wat moeite om alles goed op elkaar af te stemmen.

[xFeverr]

@ard1998 Foei! Een C# klasse én een C# methode in lowercase, ongelofelijk! En dan ook niet eens zo'n mooie interpolated string gebruiken...

Alle gekheid op een stokje, even serieus: je hoeft je hele applicatie in WebAPI echt niet Async te maken. ASP.Net doet zijn eigen stukje multi threading en kan al meerdere verzoeken tegelijkertijd afronden, want die worden al in aparte threads gestoken. Het zou inderdaad drama zijn als je met 50 users op een site was en je moest alle 50 op elkaar wachten voordat je verzoek behandeld wordt.

^{disclaimer: uiteindelijk zou je alsnog moeten wachten op die 50 man, al hebben we het hier over miliseconden, want een pc doet maar 1 ding tegelijk.
Het is maar hoe je het bekijkt natuurlijk}

[ Voor 30% gewijzigd door xFeverr op 22-10-2017 14:46 ]

[HawVer]

xFeverr schreef op zondag 22 oktober 2017 @ 14:42:
@ard1998 Foei! Een C# klasse én een C# methode in lowercase, ongelofelijk! En dan ook niet eens zo'n mooie interpolated string gebruiken...

Alle gekheid op een stokje, even serieus: je hoeft je hele applicatie in WebAPI echt niet Async te maken. ASP.Net doet zijn eigen stukje multi threading en kan al meerdere verzoeken tegelijkertijd afronden, want die worden al in aparte threads gestoken. Het zou inderdaad drama zijn als je met 50 users op een site was en je moest alle 50 op elkaar wachten voordat je verzoek behandeld wordt.

^{disclaimer: uiteindelijk zou je alsnog moeten wachten op die 50 man, al hebben we het hier over miliseconden, want een pc doet maar 1 ding tegelijk.
Het is maar hoe je het bekijkt natuurlijk}

Bedankt voor je antwoord. Het scheelt inderdaad dat ASP .NET zijn eigen threadpool heeft. Maar als je meer request krijgt dan dan je threads hebt zit je alsnog te wachten. Dit probleem kun je oplossen door (een deel van) je code async te maken. Ik lees wel overal dat wanneer je ergens begint met async maken van je applicatie je net zo goed alles async kan maken omdat de aanroepende methode ook async moet zijn.

[xFeverr]

Je hebt het over een maximum aantal threads, maar zodra je async werkt, wordt dit weer afgewerkt in nog een andere thread. Je krijgt er dan twee per request.

Ik las trouwens net dat een 64bit systeem op .NET framework 4.0 een maximum zou hebben van 32768 threads, niet echt reden tot paniek dus. Geen idee hoe dit zit met latere versies.

Is het trouwens niet zo dat de aanroepen de methode alleen async hoeft te zijn als die aanroepende methode er op moet wachten? Zolang je geen await gebruikt hoef je die methode niet async te maken.

[whoami]

xFeverr schreef op maandag 23 oktober 2017 @ 08:36:
Je hebt het over een maximum aantal threads, maar zodra je async werkt, wordt dit weer afgewerkt in nog een andere thread. Je krijgt er dan twee per request.

De async & await keywords zorgen er niet voor dat er een nieuwe thread gestart wordt:

It’s important to reason about tasks as abstractions of work happening asynchronously, and not an abstraction over threading. By default, tasks execute on the current thread and delegate work to the Operating System, as appropriate. Optionally, tasks can be explicitly requested to run on a separate thread via the Task.Run API.

bron

Zeker voor I/O operaties heb je geen aparte thread nodig; de thread waarop de IO task gestart werd, is beschikbaar om iets anders uit te voeren, terwijl er gewacht wordt op de I/O operatie.

This model works well with a typical server scenario workload. Because there are no threads dedicated to blocking on unfinished tasks, the server threadpool can service a much higher volume of web requests.
Consider two servers: one that runs async code, and one that does not. For the purpose of this example, each server only has 5 threads available to service requests. Note that these numbers are imaginarily small and serve only in a demonstrative context.
Assume both servers receive 6 concurrent requests. Each request performs an I/O operation. The server without async code has to queue up the 6th request until one of the 5 threads have finished the I/O-bound work and written a response. At the point that the 20th request comes in, the server might start to slow down, because the queue is getting too long.
The server with async code running on it still queues up the 6th request, but because it uses async and await, each of its threads are freed up when the I/O-bound work starts, rather than when it finishes. By the time the 20th request comes in, the queue for incoming requests will be far smaller (if it has anything in it at all), and the server won't slow down.

Zowiezo is het werken met async / await eigenlijk hetzelfde zoals je voorheen zou doen met het async pattern dmv de Beginxxxx & Endxxxx methods

[HawVer]

xFeverr schreef op maandag 23 oktober 2017 @ 08:36:
Je hebt het over een maximum aantal threads, maar zodra je async werkt, wordt dit weer afgewerkt in nog een andere thread. Je krijgt er dan twee per request.

Ik las trouwens net dat een 64bit systeem op .NET framework 4.0 een maximum zou hebben van 32768 threads, niet echt reden tot paniek dus. Geen idee hoe dit zit met latere versies.

Ik bedoel het maximale aantal threads in de threadpool van ASP.NET. In de opties van Kestrel kun je een maximum aantal threads meegeven. Als alle threads bezig zijn kunnen er niet meer requests afgehandeld worden. Zie MSDN: Async Programming - Introduction to Async/Await on ASP.NET

Is het trouwens niet zo dat de aanroepen de methode alleen async hoeft te zijn als die aanroepende methode er op moet wachten? Zolang je geen await gebruikt hoef je die methode niet async te maken.

Ik lees in artikelen dat het async all the way is en dat je anders vrij grote kans hebt op deadlock problemen. Bron: https://gathering.tweaker.../quote_message/52979657/0

[ Voor 6% gewijzigd door HawVer op 23-10-2017 11:47 ]

[Woy]

Kijk deze webcast eens: https://channel9.msdn.com...ync-programming-deep-dive

Dat legt een hele hoop uit. 1 van de belangrijke dingen om te beseffen is dat async/await in de basis niet met multi-threading te maken heeft. De taak waarop je await hoeft namelijk helemaal geen aparte thread te zijn, het zal vaak gaan om async IO taken die gewoon de scheduler notify'en als ze klaar zijn.

[whoami]

Conclusie

HawVer schreef op donderdag 19 oktober 2017 @ 22:21:

Vraag 1: kan ik vanuit de code die asynchroon wordt uitgevoerd een functie aanroep die niet de async modifier bevat? Wordt dan de aanroepende code ook synchroon uitgevoerd? Bijvoorbeeld

C#:

public async Task<int> ExampleMethodAsync()  
{  
    Method();
} 

public void Method()
{
 // 
}

Ja, er is niets om op te awaiten in jouw voorbeeld. De compiler zal hier ook een warning op geven.

Vraag 2: Hoe vaak kom je problemen tegen in code die async await wordt uitgevoerd en die ontstaan zijn door multithreading problematiek. Overal lees je in artikelen over race conditions en deadlock problemen die erg moeilijk zijn op te lossen. Maar ik kom erg weinig artikelen tegen die vertellen hoe je deze problemen kan voorkomen. Ik ben dus niet op zoek naar hoe een mutex, locks en semaphores werken, maar ik ben op zoek naar
a.. moet ik ze uberhaupt inzetten bij async await?

Nee. Locks / mutexes heb je nodig als je met shared state gaat werken. De deadlocks waarover sprake in de literatuur, zijn deadlocks die optreden omdat er op dezelfde thread gewacht wordt op een Task die ook door diezelfde thread moet uitgevoerd worden.
Dit voorkom je door alles async te maken (tot op je top-level method) en correct iedere keer te awaiten of door gebruik te maken van ConfigureAwait(false), echter, met dat laatste moet je ook oppassen wat je doet.

[Fexxman]

Op een gegeven moment komt mijn programma uit bij de await aanroep. De code die ik daarmee aanroep wordt in een andere thread uitgevoerd.

Niet noodzakelijk.
https://stackoverflow.com...hen-how-does-it-make-appl

Wordt dan de aanroepende code ook synchroon uitgevoerd?

Dat kun je stellen binnen de executie van de thread waarop de code wordt aangeroepen. Hopelijk klinkt dat logisch.

Hoe vaak kom je problemen tegen in code die async await wordt uitgevoerd en die ontstaan zijn door multithreading problematiek.

Naar mijn inziens weinig aangezien async en await ervoor kunnen zorgen dat je geen interactie met threads meer nodig hebt terwijl ze mogelijk wel gebruikt worden op de achtergrond. Problemen ontstaat echter vaak wanneer async en await verkeerd worden gebruikt. De vuistregel die je kunt hanteren is "don't block on async code".

https://blog.stephenclear...-block-on-async-code.html

Mijn red flags tijdens code reviews:

• Task.Result (op een Task die niet gegarandeerd completed is)
• Task.Wait()
• Task.WaitAll()
• Task.WhenAll()

De laatst genoemde link legt ook uit wat ConfigureAwait(false) doet en wanneer je het kan gebruiken.

[ Voor 3% gewijzigd door Fexxman op 27-10-2017 21:29 ]

[Verwijderd]

Misschien nog een beetje jong maar.. je kan ook kijken naar F# met ASP.NET

- Je wordt gedwongen om zoveel mogelijk stateless te zijn. (Dit is F#)
- Asynchroon is dus doordat F# functioneel is makkelijker toe te passen.

Volgens mij wordt het steeds interessanter om nu in plaats van je C# code met hoofdpijn zo stateless te maken en asynchroon, gewoon de boel over te zetten naar F#.

Het voelt mij als plakband oplossing in plaats gewoon van naar volledig functioneel te gaan.
Maar er zijn natuurlijk wel andere afwegingen in een bedrijf om het dan niet te doen. Maar als je gehele C# project niet te groot is zou ik dat liever doen.

Het is een keuze, wil je je software optimaliseren of gewoon hardware kopen. Want volgens mij was je doel dat je server meer verzoeken tegelijkertijd kan afhandelen.

Async programmeren in C# zal veel meer tijd kosten als in F# omdat het daar meer eigen is. Maar je code is C# en dus zal het veel geld kosten om heel je C# code om te gooien naar iets wat nooit mooi blijft en netjes zoals in F#.

Ik zou dan voor het goedkoopste gaan: Hardware. Als het om geld draait. Is geld geen optie: Boel omzetten naar F# voor de huidige hardware.

[HawVer]

Bedankt voor alle reacties! Wordt zeer gewaardeerd!

Verwijderd schreef op zaterdag 28 oktober 2017 @ 10:29:
Misschien nog een beetje jong maar.. je kan ook kijken naar F# met ASP.NET

- Je wordt gedwongen om zoveel mogelijk stateless te zijn. (Dit is F#)
- Asynchroon is dus doordat F# functioneel is makkelijker toe te passen.

Volgens mij wordt het steeds interessanter om nu in plaats van je C# code met hoofdpijn zo stateless te maken en asynchroon, gewoon de boel over te zetten naar F#.

Het voelt mij als plakband oplossing in plaats gewoon van naar volledig functioneel te gaan.
Maar er zijn natuurlijk wel andere afwegingen in een bedrijf om het dan niet te doen. Maar als je gehele C# project niet te groot is zou ik dat liever doen.

Het is een keuze, wil je je software optimaliseren of gewoon hardware kopen. Want volgens mij was je doel dat je server meer verzoeken tegelijkertijd kan afhandelen.

Async programmeren in C# zal veel meer tijd kosten als in F# omdat het daar meer eigen is. Maar je code is C# en dus zal het veel geld kosten om heel je C# code om te gooien naar iets wat nooit mooi blijft en netjes zoals in F#.

Ik zou dan voor het goedkoopste gaan: Hardware. Als het om geld draait. Is geld geen optie: Boel omzetten naar F# voor de huidige hardware.

Ik ben nog redelijk aan het begin van het project. F# zou zeker nog een optie zijn. Had alleen begrepen dat stateless niet echt van toepassing is wanneer je opslaat in een database (=state). Dus vandaar dat ik F# nooit echt heb overwogen.