viernes, 29 de octubre de 2010 21:10
I've saw the PDC demo of the async CTP.
I've been working with CCR framework for a year now and it is simply the best thing I've ever use for concurrent applications.
But, the best thing about the CCR is the coordination abilities which, in my opinion, are missing from async.
Async, like most other concurrent frameworks, give us the ability to WaitOne or WaitAny, now it also give us to chin tasks but coordination is more than that, it means be able to wait for 3 out of 4 task to complete in simple and clear way, it means be able to tell when things should be serialized and not be concurrent and it means coordinate handling of exceptions, not ignore the fact exception are different in concurrent applications.
I'll be happy to know if the async/await implementation has any relation to the CCR, and if not why not.
Also I'll be glad to see some technical documents about how async/await is implemented (not power-point, real code).
Todas las respuestas
viernes, 29 de octubre de 2010 21:33Moderador
The Async CTP includes a new DLL, System.Threading.Tasks.Dataflow.dll, which incorporates those kind of coordination and message passing constructs. It's based heavily on concepts from the CCR, from Axum, and from the native Asynchronous Agents library in VC++ 10. It also integrates very well with the new language support. You can await receiving from dataflow blocks, you can create dataflow blocks that asynchronously process messages using the new async language features, and much more.
The document available at http://go.microsoft.com/fwlink/?LinkId=205053 provides more details (this document is also included in the CTP), and the DLL is installed as part of the Async CTP install. Feedback is welcome and encouraged.
Regarding technical documents, the C# language specification for the feature is available at http://go.microsoft.com/fwlink/?LinkId=204845, and the VB language specification is available at http://go.microsoft.com/fwlink/?LinkId=204846. A detailed deep-dive into using the new Task-based Async Pattern and how to use it is also available at http://go.microsoft.com/fwlink/?LinkId=204847.
I hope that helps.
- Propuesto como respuesta Stephen Toub - MSFTMicrosoft Employee, Moderator viernes, 29 de octubre de 2010 21:33
sábado, 30 de octubre de 2010 9:45
Thank you very much for the quick and detailed answer. I will go into the documents.
I understand the the async/wait incorporates ideas from all the other frameworks (Axum is actually CCR) but does it compose well together, and I think the answer is not really.
From what I can see Microsoft try all kind of ways to go about concurrency: TPL, APM, CCR, Axum (although it built on CCR) and now async/await. That make sense because it is a difficult problem. Also in recent years we have shift from faster and faster computers to more and more cores. To take advantage of it we must split the work between all the cores.
Interesting enough the same building block use for single processor multitask, that is thread, is also use for multicore work splitting. TPL look like better fit for parallel computation while CCR is built for better I/O concurrency but they both can do the other job well enought.
My question is simple: Does Microsoft choose async/await over the other patterns or does it still supporting them all?
Another question is do you have something like the Arbiter in CCR which is the source of power for doing coordinated work?
sábado, 30 de octubre de 2010 18:59
After further reading of the TAP (Task Async Pattern) document I can see that there are more problem to think about.
One of the key principles in CCR is decouple of caller from calle. In TAP it is the exact opposite: when you call an async method the part of the method before the await operator is synchronous and block the caller, also the IProgress interface may be implemented in a way that will block the async method from continue.
Cancelation is done in all-or-nothing maner which I agree is 80% of the times, but what if I don't want to cancel the operation, just reduce the precision of on-going operation?
Exception is yet another thing that handled much cleaner in CCR: if I fire 5 async operations, each of which might success or fail, I want to wait for 5 results, either success or failure. Wiring code like try/catch simply does not express my intentions for it, it look more like fire 5 operation and if 1 fail ignore the rest. Also things like fire 5 operations and only if 3 fail do something is pretty hard to do and not so declarative like in the CCR.
The CCR is built on one simple concept which is Port. Everything is done using Port: start operation, send progress report, cancelation, communication with on-going operation. In ATP each of those things is special case which makes it really hard to do some stuff and impossible to do others.
domingo, 31 de octubre de 2010 6:01Moderador
Please take a look at the TPL Dataflow document. System.Threading.Tasks.Dataflow.dll incorporates many of the key ideas from the CCR and enables you to implement the same kinds of problems with the same expressivity, while also integrating with the async language functionality.
After reading through that doc and exploring the library, if you still see gaps, it'd be great if you could outline them for us. That way, we can either demonstrate how it's possible to achieve what you want with the dataflow library and/or the async language functionality, or we can take that as feedback that we're missing some important cases.
Your example of 5 async operations where you want to wait for all five to complete either successfully or with failures is what the Task.WhenAny combinator provides, e.g.
Task<T1> t1 = ...;
Task<T5> t5 = ...;
await Task.WhenAll(t1, t2, t3, t4, t5);
... // process exceptions here
The dataflow library also includes the BatchedJoinBlock, which is very similar to CCR's arbiter for batching multiple results of different types.
domingo, 31 de octubre de 2010 7:44
Thanks again for the answer. I will read through the document and I've also download the Channel9 videos to get more insight.
I'll change my way of approaching this. Instead of comparing CCR and async I'll try to take the strong part of async which is combine async methods with UI and strong part of CCR which is coordination and combine them.
I hope I'll find them complementary to each other.
Good luck to all,
domingo, 31 de octubre de 2010 19:07ModeradorThanks, Ido. We'll appreciate any and all further feedback you can provide.
lunes, 01 de noviembre de 2010 18:36
I've watched your video in Channel9 - Task Async Deep Dive, and it really explain a lot clearer what you have done.
I was happy to finally hear that George and the CCR library names :)
I still didn't see exactly how you are using SynchronizationContext but I can guess that part, I think.
I would like to ask if you try combine ATP with CCR?
I have my DAL written in CCR and it works great. The problem was to connect it to my UI layer. I do all the SynchornizationContext switches and Post myself but it is very difficult and expose to errors that hard to debug and fix.
I guess I can fire a CCR work, pass it a Port to which the result will be posted and register my Receiver, then create a Task which will be signal when the Receiver is activated. The Task will be return and I'll be able to await on it while the CCR does it thing.
Did I assume here something wrong?