Timeline for Calling multiple async services in parallel
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 22, 2018 at 23:15 | comment | added | Andy | @MetaFight If awaiting results in an IO bound operation, the await immediately frees the thread to do other work, so even the simple example is making good using of async/await. | |
| Jul 17, 2018 at 13:43 | answer | added | user1451111 | timeline score: -2 | |
| May 10, 2018 at 6:39 | review | Close votes | |||
| May 15, 2018 at 3:04 | |||||
| May 10, 2018 at 6:20 | history | protected | gnat | ||
| May 10, 2018 at 1:26 | history | tweeted | twitter.com/StackSoftEng/status/994388080676233216 | ||
| May 9, 2018 at 22:49 | answer | added | Jay Shah | timeline score: 1 | |
| Jan 8, 2017 at 0:15 | comment | added | MetaFight | @Servy, I didn't say no threads were used. I said no new threads were spawned. Also, using await with Task.WhenAll() is hardly leveraging async await. Doing something like var result1 = service1.GetFooAsync(); doOtherStuff(); var result2 = service2.GetBarAsync(); var baz = doMoreStuff(await result1); return mix(baz, await result2); is making better use of the feature. The async await allows async code while still keeping it grouped logically. All the steps in your algorithm will still appear sequentially, even though blocking and continuation magic happens automatically. | |
| Jan 7, 2017 at 21:08 | comment | added | Servy | @MetaFight Sure they are. Since you await the call to WhenAll the method is asynchronous. Whether you await or call Result on the already completed Task isn't that different. They have slightly different error handling behaviors, but that's about it. | |
| S Jan 7, 2017 at 13:52 | history | suggested | DasJacko | CC BY-SA 3.0 | parallely is not a word. |
| Jan 7, 2017 at 1:49 | review | Suggested edits | |||
| S Jan 7, 2017 at 13:52 | |||||
| Jan 6, 2017 at 16:43 | comment | added | Servy | @MetaFight Not even a single thread, it wouldn't use any threads at all. The one thread would start the operations and then would be free to go off doing other work while these requests are going on, meaning that these requests are consuming no thread's time, rather than even a single thread. | |
| Jan 6, 2017 at 16:41 | answer | added | Servy | timeline score: 20 | |
| Jan 6, 2017 at 10:51 | comment | added | Ankit Vijay | I'm still doing an await on WhenAll. So, this way I understand I'm able to use the best of both world. Right? | |
| Jan 6, 2017 at 8:42 | review | Close votes | |||
| Jan 18, 2017 at 3:02 | |||||
| Jan 6, 2017 at 5:31 | comment | added | MetaFight | Yes, if you Task.WhenAll(...) first then your task.Result should return immediately. If you do this, however, you're not really leveraging async await though. | |
| Jan 6, 2017 at 5:21 | comment | added | Ankit Vijay | @MetaFight In my second example I'm doing WhenAll before I do Result with the idea that it completes all the tasks before .Result is called. Since, Task.Result blocks the calling thread, I presume that if I call it after the tasks are actually completed it would return thre result immediately. I want to validate the understanding. | |
| Jan 6, 2017 at 4:06 | comment | added | MetaFight | It might be easier to give you a more satisfying answer if you provided a less abstract example of the code consuming both service responses. | |
| Jan 6, 2017 at 4:05 | comment | added | MetaFight | @Ankit it depends one when it's appropriate for your code to block. Your second example would block until both responses are ready. Your first example, presumably, would only logically block when the code would attempt to use the response (await) before it is ready. | |
| Jan 6, 2017 at 4:01 | comment | added | MetaFight | @RobertHarvey I'm guessing the concern is that, in this context, Parallel.ForEach would spawn new threads whereas async await would do everything on a single thread. | |
| Jan 6, 2017 at 3:11 | comment | added | Robert Harvey | I do not think I can use Parallel.ForEach here since it is not CPU bound operation -- I don't see the logic there. Concurrency is concurrency. | |
| Jan 6, 2017 at 2:46 | history | asked | Ankit Vijay | CC BY-SA 3.0 |