TPL – konkurenční, paralelní a asynchronní kód pro náročné René Stein

Prezentace na téma: "TPL – konkurenční, paralelní a asynchronní kód pro náročné René Stein"— Transkript prezentace:

1 TPL – konkurenční, paralelní a asynchronní kód pro náročné René Stein http://renestein.net

2 TPL základy – co byste měli znát Třída Task. „Thread je mrtev, ať žije Task“? Spuštění tásku a základní operace pro skládání tásků (WaitAny, WaitAll). Kooperativní stornování tásku. Co je synchronizační kontext a proč máme metodu ConfigureAwait. Klíčová slov async a await v C#.

3 TPL základy – co byste měli znát II Asynchronní != paralelní. (a asynchronní nebo paralelní != zázrak) Proč bychom neměli používat async void metody. Jaký je životní cyklus objektu tásku? (Toto by neměl být váš životní cyklus) „Přišel jsem, viděl jsem, bohatě stačilo a (nejpozději po svačině) rád odcházím“

4 Životní cyklus tásku Zdroj: http://blog.stephencleary.com/2014/06/a-tour-of-task-part-3-status.html

5 Něco jednoduchého – problémy s TaskCompletionSource „Co jednou Task spojil, toTaskCompletionSource musí rozdělit“ Věčnost?

6 TaskCompletionSource TaskCompletionSource = Promise. Task = Future. I při kódování by se sliby měly plnit. I když to občas znamená, že ten druhý si bude přát, abyste mu nikdy nic neslíbili, protože může od vás čekat je krev, pot, slzy, deadlock, a když jste v dobrém rozmaru, tak výjimku BTW:Jsou sliby oboustranné?

7 Rstein.Async – DebugTaskCompletionSource DebugTaskCompletionSourceServices. DetectBrokenTaskCompletionSources(); (Detekce nesplněných slibů bez záruky - jde jen o preview verzi) Idioti jsou jako láska - slibují víc, než mohou splnit. (G. Laub) Na TaskCompletionSource bych v této souvislosti nezapomínal! (Dodatek: René Stein) Každý slib je na nejlepší cestě k tomu být falešný. (J.P. Sartre)

8 Scheduler a ThreadPool TPL scheduler.Net ThreadPool TPL scheduler se má k.Net ThreadPoolu jako ?

9 Co s hříšnými touhami po jiném Scheduleru? Potřebujeme jiné schedulery než ty, které jsou v.Net Frameworku? –„ThreadPoolScheduler“ - Default –„SynchronizationContextScheduler“ FromCurrentSynchronizationContext() –ConcurrentExclusiveSchedulerPair (náhrada za „lock“, ReaderWriterLock) !!! Většinou ne !!! - ale když už ano

10 „Extra“ schedulery v PEE Další slušnou sbírku schedulerů naleznete v Parallel Extensions Extras http://code.msdn.microsoft.com/ParExtSamples

11 Vlastní scheduler Nejjednodušší je podle mě: CurrentThreadScheduler (A v téhle jednoduchosti fakt nehledejte žádnou krásu)

12 Vlastní scheduler – problémy a řešení (Otravný) FallbackScheduler, který může použít CurrentThreadSche duler jako záložní scheduler

13 Rstein.Async – dvojice IProxyScheduler a ITaskScheduler Integrace s TPL – „obyčejný“ TaskScheduler

14 Rstein.Async – ProxyScheduler a TaskSchedulerBase

15 FallbackScheduler s pořadovým číslem 2 je sice stále nudný, ale už jej alespoň dokážeme napsat a používat bez vyvolání výjimky. FALLBACKSCHEDULER II

16 Rstein.Async a IoServiceScheduler Scheduler, který nevyřídí žádný tásk do té doby, dokud mu nepropůjčíte vlákno zavoláním jedné z jeho metod Poll, PollOne, Run, RunOne Boost.Asio.Net

17 Rstein.Async - IoServiceSynchronizationContext

18 Rstein.Async a IoServiceThreadPoolScheduler „Autonomní“ scheduler. (Velmi) jednoduchý threadpool. Používá IoServiceScheduler.

19 Nelehký životní cyklus SimpleUploaderu Jak by řekla nejen programátorka Maruška – funkčnost a čitelnost kódu nad zlato i rychlost. V praxi se nejčastěji setkáte s kódem, který je: –Občas nefunkční, ale nikdo neví „proč“. –Nečitelný, ale všichni vám zdůvodní „proč“. –Po čase pomalý a plný (dead)locků, které jsou zpestřením nudného vývojářského života. Proč?

20 Aktor model Zjednodušeně – aktor je objekt (prozatím nekamenovat!), u kterého platí, že v jednom okamžiku zpracovává maximálně jednu zprávu („provádí jednu metodu“). A to bez ohledu na počet požadavků z různých vláken. Všechny požadavky na aktora jsou aktorem zpracovány sekvenčně!

21 Aktor jako objekt z lepší společnosti Objekty, u kterých se při volání metody může změnit jejich interní stav (a přitom se zbavíme „locků“) Aktor je (prý) lepší objekt než “klasické“ objekty (nejen) z C- like jazyků.

22 Charakteristika konvenčního aktor modelu Aktor při zpracování zprávy („po obdržení požadavku“) může: –Poslat zprávy (požadavky) dalším aktorům. –Změnit svůj stav. A připravit se tak na příjem další zprávy (požadavku). –Vytvořit další aktory pro zpracování nových zpráv (požadavků).

23 Aktoři a thready Jak zabít aktory i s aplikaci? Frontu požadavků každého aktora obsluhuje právě jeden thread. Tento thread je v exkluzivním vlastnictví aktora. Co je „threadless“ actor model?

24 Rstein.Async - StrandSchedulerDecorator STRAND = v jednom okamžiku běží maximálně jeden tásk Implicitní strand = m_originalScheduler.Maxim umConcurrencyLevel = 1 StrandSchedulerDecorator ITaskScheduler (nejčastěji IoServiceThreadPoolScheduler)

25 Rstein.Async - podpora pro aktory Použita dynamická proxy Castle.DynamicProxy var uploaderActorProxy = proxyEngine.CreateProxy (simpleUploaderActor ); ProxyGenerationHook „Jaké metody budeme odchytávat v interceptorech“ ActorMethodInterceptor „metody budou zpracovány sekvenčně – každý aktor má svůj StrandScheduler“ PreventArgumentBaseTypeLeakInterceptor „Aktor nevydá svou pravou podstatu z žádné metody, ale vždy si navlékne proxy masku“

26 Tradiční ukázky aktorů I Ping Pong (Tomáš Aquinský proti Sigeru Brabantskému)

27 Tradiční ukázky aktorů II (Problematický) Ping Pong s čekáním na odpověď Podle mě je takzvaný „ASK“ vzor pro většinu scénářů antivzor. „Don‘t ASK“ Actor by měl komunikovat s ostatními aktory stylem „Fire & Forget”. –Budeme čekat na odpověď a blokovat zpracování dalších zpráv? –Zpracujeme jinou zprávu? (co vnitřní stav aktora?)

28 Schéma komunikace mezi aktory - ukázka III ILibraryActor IBookLinesParser Actor IBookLineConsumerActor n (CountWordsInLineActor) ICountWordAggregate Actor IBookLineConsumerActor 1 (CountWordsInLineActor) IResultProcessorActor (PrintTopWordsProces sorActor)

29 Co naši aktoři prozatím nepodporují O „pravém“ actor modelu (Erlang, Elixir…) se dá mluvit teprve tehdy: –Jsme-li schopni aktory od sebe dokonale izolovat. –Jsme-li schopni aktory aktivovat v jiném procesu/na jiném počítači (distribuovaní aktoři). Ošetření chyb např. elegantním a vývojáři milovaným stylem „Let it crash“. Přesto – i „naši“ zjednodušení aktoři jsou pro mnoho aplikací požehnáním

30 Alternativní knihovny pro psaní aktorů TPL Dataflow – např. pomocí ActionBlocku s konkurencí rovnou jedné. ActorFX - http://actorfx.codeplex.com/wikipage?title=ActorFx%20Basics http://actorfx.codeplex.com/wikipage?title=ActorFx%20Basics F# Zdroj: http://blogs.msdn.com/b/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspxhttp://blogs.msdn.com/b/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx

31 AKKA.NET Zdroj: https://github.com/akkadotnet/akka.net/issues/144https://github.com/akkadotnet/akka.net/issues/144

32 Tradiční problémy s aktory Jestliže aktoři mohou modifikovat stav „zpráv“ (argumentů metod), máte „race condition“. Zprávy-argumenty musí být imutabilní. Ani použití aktorů neznamená jistotu, že se v aplikaci neobjeví deadlock. Jeden aktor se může snadno stát brzdou pro ostatních aktory. Výkonnostní problémy.

33 Alternativní konkurenční modely TPL Dataflow Reactive Extensions – RX framework Software transactional memory Communicating Sequential Processes (CSP) a mnoho dalších

34 Zdroje – malý výběr Knihovna Rstein.Async. https://bitbucket.org/renestein/rstein.async/ Seriál na blogu o knihovně (prozatím 5 dílů) http://jdem.cz/ba8kp3http://jdem.cz/ba8kp3

35 Answer? answer = await Task.Run(()=> ); Dotazy

36 René Stein Vývoj aplikací, veřejné a inhouse kurzy http://www.renestein.net/nabidka.aspx http://blog.renestein.net http://twitter.com/renestein