Asynchronous Programming Lab @ DotNetToscana
•Download as PPTX, PDF•
0 likes•371 views
Slide utilizzate durante il DotNetToscana - Asynchronous Programming Lab (http://www.dotnettoscana.org/asynchronous-programming-lab.aspx)
Recommended
More Related Content
What's hot
What's hot (13)
Similar to Asynchronous Programming Lab @ DotNetToscana
Similar to Asynchronous Programming Lab @ DotNetToscana (20)
More from Matteo Baglini
More from Matteo Baglini (11)
Recently uploaded
Recently uploaded (20)
Asynchronous Programming Lab @ DotNetToscana
- 1. Matteo Baglini Software Architect/Developer, Freelance Email: matteo.baglini@gmail.com Web: http://www.makesimple.net Blog: http://blogs.ugidotnet.org/bmatte
- 2. «.NET: applicazioni veloci come la luce. Scopri come velocizzare le applicazioni con la programmazione asincrona» 2
- 3. «Programmazione asincrona e programmazione parallela sono sinonimi» 3
- 4. Windows 4
- 5. Thread 5
- 6. Thread Madness 6
- 7. Modern CPU 7
- 8. Asynchronous 8
- 9. Parallel 9
- 10. CPU-Bound 10
- 11. CLR Thread Pool - UserWorkItem Global Queue (FIFO) Worker … Worker Thread 1 Thread N Work1 Program Work2 Thread
- 12. CLR Thread Pool - Tasks Local Local Queue … Queue Global 1 N Queue (LIFO) (LIFO) (FIFO) Worker … Worker Thread 1 Thread N Task 6 Task 1 Program Task Task 3 4 Task 2 Task 5 Thread
- 13. I/O-Bound 13
- 14. var readed = fileStream.Read(buff, 0, buff.Length); ReadFile(hFile, Buff, BUFFSIZE-1, &dwReaded, NULL); Windows I/O Subsystem Thread Hardward does I/O. block, waits No threads involved! for I/O completion. 14
- 15. fileStream.BeginRead(buff, 0, buff.Length, cb, null); void EndReadCb(IAsyncResult asyncResult) {…} ReadFile(hFile, Buff, BUFFSIZE-1, &dwReaded, NULL); Windows I/O Subsystem ThreadPool Hardward does I/O. No threads I/O involved! Completion Ports 15
- 16. App Threading Models 16
- 17. while ( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) { // handle error / exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } } 17
- 18. Parallel 18
- 19. Async/Await 19
- 20. Coroutine 20
- 21. WinRT 21
- 22. 22
- 23. 23
- 24. • Principio: • Non bloccare i Thread. • Pattern: • Operazioni I/O-bound: conviene sempre effettuarle in asincrono. • Operazioni CPU-bound: dipende dal contesto e dal costo (computazionale). 24
- 25. Primary Secondary Parent/ Return/ Model Progress Cancel Wait Timeout Use Use Child Exception Queue CPU Sync I/O No No No No No No WorkItem CPU via APM I/O No No No Si No Si BeginInvoke CPU via EAP I/O Background No Alcuni Alcuni No No Si Worker Si, via Sync I/O or TAP CPU Si No Cooperative Si Si Si FromAsync Cancellation Si, via Timer CPU Sync I/O No No No Si No Dispose 25
- 26. 26
- 27. • The Task-based Asynchronous Pattern • Asynchronous Programming in C# and Visual Basic • Diving deep with WinRT and await • http://blogs.msdn.com/b/pfxteam • http://blogs.msdn.com/b/dotnet/ • 101 Async Samples 27
Editor's Notes
- Prima di andareavanticapiamomeglio come operanoi Worker Thread del ThreadPool. QuandovieneinvocatoilmetodoQueueUserWorkItemdellaclasseThreadPoolilrelativoWorkItemvienemesso in una coda di lavoroglobale.Ogni Worker Thread cerca di prelevare un item usando un algoritmo di tipo FIFO.Unavoltapreso in carico, ilWorkItem, vienesemplicementeeseguito.Quando un Worker Thread terminal’esecuzione del WorkItemverifica se ci sonoaltrielementinella coda, se ci sono continua a prelevare, mentre se non ci sonosiimposta in Sleep.Passato un certo lasso di tempo il Worker Thread sisveglia e si auto termina in modo da liberare le risorse.Datoche la coda come dice ilnomestesso è globalel’accessoavviene in manieraconcorrentequindic’è un elevatorischio di conflitto.Nellevecchieversioni del framework l’accesso a questacosa era veicolato da un lock, il quale diventava un collo di bottiglia in caso di un elevatolavoroparallelo.Per questomotivonellaversione 4.0 è statautilizzatauna lock-free collection chepermette di scalaremeglio. DEMO - ThreadPoolMaxActiveThreadPRATICA - CPUBoundAPMPRATICA - CPUBoundTAP
- Quandousiamoi Task ilfunzionamentodiventa un po’ piùarticolato.Come nelcasodeiWorkItemquando un Task vieneschedulatovieneposizionatonella coda globale e prelevatodai Worker Threads.Fin qui niente di nuovo. Però se un Task in esecuzione genera altri Task, questivengonomessi in una coda locale al Worker Thread.Terminatoil Task in corsoil Worker Thread preleva un nuovo Task da processare, questavoltautilizzando un algoritmo di tipo LIFO, per motivi di ottimizzazione, perchè molto probabilmenteilnuovo Task dovràlavorare con idatiappenagenerati dal vecchio Task, quindiancorapresenti in cache.Datocheil Worker Thread è l’unico Thread in grado di accedereallatestadella coda locale in questocaso non avviene un accessoconcorrente.Quando la coda di un Worker Thread è vuotaquet’ultimoruba un Task dalla coda locale di un’altro Worker Thread utilizzando un algoritmooppostoovvero FIFO, in questocasovieneprelevato un elemento in coda e non dallatesta al fine di ridurre I conflitti e preservare la cache.Quando non ci sonopiù Tasks nelle code localii Worker Thread tornano a prelevaredalla coda globale.Da qui in poi tornatutto come prima, quindi se non c’èpiùlavoro da svolgerei Worker Threads vanno in Sleep per un certo lasso di tempo, dopo di che se continua a non essercilavorosi auto terminano.