TPL – konkurenční, 
paralelní a asynchronní 
kód pro náročné 
René Stein 
http://renestein.net
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 pr...
TPL základy – co byste měli 
znát II 
• Asynchronní != paralelní. (a asynchronní 
nebo paralelní != zázrak) 
• Proč bychom...
Životní cyklus tásku 
Zdroj: http://blog.stephencleary.com/2014/06/a-tour-of-task-part-3-status.html
Něco jednoduchého – problémy 
s TaskCompletionSource 
„Co jednou Task spojil, 
toTaskCompletionSource 
musí rozdělit“ 
Věč...
TaskCompletionSource 
• TaskCompletionSource = Promise. 
• Task = Future. 
• I při kódování by se sliby měly plnit. I když...
Rstein.Async – 
DebugTaskCompletionSource 
Idioti jsou jako láska - slibují víc, než mohou splnit. (G. Laub) Na 
TaskCompl...
Scheduler a ThreadPool 
TPL scheduler .Net ThreadPool 
TPL scheduler se 
TPL scheduler se 
má k .Net 
ThreadPoolu 
má k .N...
Co s hříšnými touhami po jiném 
Scheduleru? 
• 
Potřebujeme jiné schedulery než ty, které 
jsou v .Net Frameworku? 
– „Thr...
„Extra“ schedulery v PEE 
• 
Další slušnou sbírku 
schedulerů naleznete 
v Parallel Extensions 
Extras 
http://code.msdn.m...
Vlastní scheduler 
Nejjednodušší je podle mě: 
CurrentThreadScheduler 
(A v téhle jednoduchosti fakt nehledejte 
žádnou kr...
Vlastní scheduler – problémy a 
řešení 
(Otravný) 
FallbackScheduler, 
který může použít 
CurrentThreadSche 
duler jako zá...
Rstein.Async – dvojice 
IProxyScheduler a 
ITaskScheduler 
Integrace s TPL – 
„obyčejný“ 
TaskScheduler
Rstein.Async – ProxyScheduler 
a TaskSchedulerBase
FALLBACKSCHEDULER II 
FallbackScheduler s pořadovým 
číslem 2 je sice stále nudný, ale už 
jej alespoň dokážeme napsat a 
...
Rstein.Async a 
IoServiceScheduler 
• Scheduler, který 
nevyřídí žádný tásk 
do té doby, dokud mu 
nepropůjčíte vlákno 
za...
Rstein.Async - 
IoServiceSynchronizationContext
Rstein.Async a 
IoServiceThreadPoolScheduler 
• „Autonomní“ 
scheduler. 
• (Velmi) jednoduchý 
threadpool. 
• Používá 
IoS...
Nelehký životní cyklus 
SimpleUploaderu 
• Jak by řekla nejen programátorka Maruška – 
funkčnost a čitelnost kódu nad zlat...
Aktor model 
• Zjednodušeně – aktor je objekt (prozatím 
nekamenovat!), u kterého platí, že v 
jednom okamžiku zpracovává ...
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ř...
Charakteristika konvenčního 
aktor modelu 
• Aktor při zpracování zprávy („po obdržení 
požadavku“) může: 
– Poslat zprávy...
Aktoři a thready 
• Jak zabít aktory i s aplikaci? 
Frontu požadavků každého aktora 
obsluhuje právě jeden thread. Tento 
...
Rstein.Async - 
StrandSchedulerDecorator 
• STRAND = v jednom 
okamžiku běží maximálně 
jeden tásk 
• Implicitní strand = ...
Rstein.Async - podpora pro 
aktory 
• Použita dynamická proxy 
• Castle.DynamicProxy 
ProxyGenerationHook 
„Jaké metody bu...
Tradiční ukázky aktorů I 
Ping Pong 
(Tomáš Aquinský proti Sigeru 
Brabantskému)
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 ...
Schéma komunikace mezi 
aktory - ukázka III 
ILibraryActor IBookLinesParser 
Actor 
IBookLineConsumerActor n 
(CountWordsI...
Co naši aktoři prozatím 
nepodporují 
• O „pravém“ actor modelu (Erlang, Elixir…) 
se dá mluvit teprve tehdy: 
– Jsme-li s...
Alternativní knihovny pro psaní 
aktorů 
• TPL Dataflow – např. pomocí 
ActionBlocku s konkurencí rovnou jedné. 
• ActorFX...
AKKA.NET 
Zdroj: https://github.com/akkadotnet/akka.net/issues/144
Tradiční problémy s aktory 
• Jestliže aktoři mohou modifikovat stav 
„zpráv“ (argumentů metod), máte „race 
condition“. 
...
Alternativní konkurenční modely 
• TPL Dataflow 
• Reactive Extensions – RX framework 
• Software transactional memory 
• ...
Zdroje – malý výběr 
• Knihovna Rstein.Async. 
https://bitbucket.org/renestein/rstein.async/ 
• Seriál na blogu o knihovně...
Answer? answer = 
await Task.Run(()=> 
); 
Dotazy
René Stein 
• Vývoj aplikací, veřejné a inhouse 
kurzy 
• http://www.renestein.net/nabidka.aspx 
http://blog.renestein.net...
Upcoming SlideShare
Loading in …5
×

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

5,258 views

Published on

Published in: Software
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,258
On SlideShare
0
From Embeds
0
Number of Embeds
4,237
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. TPL – konkurenční, paralelní a asynchronní kód pro náročné René Stein http://renestein.net
  2. 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. 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. 4. Životní cyklus tásku Zdroj: http://blog.stephencleary.com/2014/06/a-tour-of-task-part-3-status.html
  5. 5. Něco jednoduchého – problémy s TaskCompletionSource „Co jednou Task spojil, toTaskCompletionSource musí rozdělit“ Věčnost?
  6. 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. 7. Rstein.Async – DebugTaskCompletionSource 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) • DebugTaskCompletionSourceServices. DetectBrokenTaskCompletionSources(); Každý slib je na nejlepší cestě k tomu být falešný. (J.P. Sartre) (Detekce nesplněných slibů bez záruky - jde jen o preview verzi)
  8. 8. Scheduler a ThreadPool TPL scheduler .Net ThreadPool TPL scheduler se TPL scheduler se má k .Net ThreadPoolu má k .Net ThreadPoolu jako ? jako ?
  9. 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. 10. „Extra“ schedulery v PEE • Další slušnou sbírku schedulerů naleznete v Parallel Extensions Extras http://code.msdn.microsoft.com/ParExtSamples
  11. 11. Vlastní scheduler Nejjednodušší je podle mě: CurrentThreadScheduler (A v téhle jednoduchosti fakt nehledejte žádnou krásu)
  12. 12. Vlastní scheduler – problémy a řešení (Otravný) FallbackScheduler, který může použít CurrentThreadSche duler jako záložní scheduler
  13. 13. Rstein.Async – dvojice IProxyScheduler a ITaskScheduler Integrace s TPL – „obyčejný“ TaskScheduler
  14. 14. Rstein.Async – ProxyScheduler a TaskSchedulerBase
  15. 15. FALLBACKSCHEDULER II 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.
  16. 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. 17. Rstein.Async - IoServiceSynchronizationContext
  18. 18. Rstein.Async a IoServiceThreadPoolScheduler • „Autonomní“ scheduler. • (Velmi) jednoduchý threadpool. • Používá IoServiceScheduler.
  19. 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. 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. 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. 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. 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. 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. 25. Rstein.Async - podpora pro aktory • Použita dynamická proxy • Castle.DynamicProxy ProxyGenerationHook „Jaké metody budeme odchytávat v interceptorech“ • var uploaderActorProxy = 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“ proxyEngine.CreateProxy<IService>(simpleUploaderActor);
  26. 26. Tradiční ukázky aktorů I Ping Pong (Tomáš Aquinský proti Sigeru Brabantskému)
  27. 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. 28. Schéma komunikace mezi aktory - ukázka III ILibraryActor IBookLinesParser Actor IBookLineConsumerActor n (CountWordsInLineActor) IBookLineConsumerActor 1 (CountWordsInLineActor) ICountWordAggregate Actor IResultProcessorActor (PrintTopWordsProces sorActor)
  29. 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. 30. Alternativní knihovny pro psaní aktorů • TPL Dataflow – např. pomocí ActionBlocku s konkurencí rovnou jedné. • ActorFX - 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.aspx
  31. 31. AKKA.NET Zdroj: https://github.com/akkadotnet/akka.net/issues/144
  32. 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. 33. Alternativní konkurenční modely • TPL Dataflow • Reactive Extensions – RX framework • Software transactional memory • Communicating Sequential Processes (CSP) • a mnoho dalších
  34. 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/ba8kp3
  35. 35. Answer? answer = await Task.Run(()=> ); Dotazy
  36. 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

×