3

I have a .NET 4.5.1 WCF service that handles synchronization from an app that will be used by thousands of users. I currently use Task.WaitAll as shown below and it works fine but I read that this is bad, can cause deadlocks, etc. I believe I tried WhenAll in the past and it didn't work, I don't recall the issues as I'm returning to this for review again just to make sure I'm doing this right. My concern is whether or not the blocking is needed and preferred in this use, a WCF service method hence why the WaitAll appears to work without issue.

I have about a dozen methods that each update an entity in Entity Framework 6 processing the incoming data with existing data and making the necessary changes. Each of these methods can be expensive so I would like to use parallelism mainly to get all methods working at the same time on this powerful 24 core server. Each method returns as Task as wraps its contents in Task.Run. The DoSync method created a new List and adds each of these sync methods to the list. I then call Task.WaitAll(taskList.ToArray()) and all works great.

Is this the right way of doing this? I want to make sure this method will scale well, not cause problems, and work properly in a WCF service scenario.

svick
  • 236,525
  • 50
  • 385
  • 514
Neal
  • 9,487
  • 15
  • 58
  • 101
  • I know this question is old, but there is pretty much no reason to use async inside a WCF service ever. For parallelism you can easily use `Parallel.For/Foreach` or PLINQ `.AsParallel()` in other situations. – Chris Marisic Jan 28 '16 at 00:43

2 Answers2

5

In high-scale services it is often a good idea to use async IO (which you are not - you use Task.Run). "High scale" is very loosely defined. The benefit of async IO on the server is that it does not block threads. This leads to less memory usage and less context switching. That is all there is to it.

If you do not need these benefits you can use sync IO and blocking all you like. Nothing bad will happen. Understand, that running 10 queries on background threads and waiting for them will temporarily block 11 threads. This might be fine, or not, depending on the number of concurrent operations you expect.

I suggest you do a little research regarding the scalability benefits of async IO so that you better understand when to use it. Remember that there is a cost to going async: Slower development and more concurrency bugs.

Understand, that async IO is different from just using the thread-pool (Task.Run). The thread-pool is not thread-less while async IO does not use any threads at all. Not even "invisible" threads managed by the runtime.

What I often find is: If you have to ask, you don't need it.

usr
  • 168,620
  • 35
  • 240
  • 369
0

Task.WhenAll is the non-blocking equivalent of Task.WaitAll, and without seeing your code I can't think of any reason why it wouldn't work and wouldn't be preferable. But note that Task.WhenAll itself returns a Task which you must await. Did you do that?

Todd Menier
  • 37,557
  • 17
  • 150
  • 173
  • Do you have to block in a WCF method though? Service context vs. Http context? Not sure, I should try it again but wanted to see what the opinions were here on the WCF use. Thx – Neal Mar 30 '14 at 14:47
  • No. It does appear that there's an [issue](http://stackoverflow.com/questions/12797091/operationcontext-current-is-null-after-first-await-when-using-async-await-in-wcf) with `OperationContext` being null after `await`, but if you need it, I'd follow the simple advice in that link and capture it manually. Much better than blocking all these threads. – Todd Menier Mar 30 '14 at 15:41