4 ms·
Yes, but I think he also meant things like the TPL, PLINQ, TPL Dataflow, RX, Akka.NET and so on. I have been happily using one or more of these to write tons of
by m_fayer 10y ago
Yes, but I think he also meant things like the TPL, PLINQ, TPL Dataflow, RX, Akka.NET and so on. I have been happily using one or more of these to write tons of event driven and/or parallel client-side code and haven't touched a lock in years.
And libraries exposing APIs through observables is a great idea.
- eropple 10y agoI don't dislike TPL and PLINQ (though I don't much care for Akka.NET at all), but at the same time I pretty regularly write code with locks. There are problems for which the simplest solution is to treat it stupidly and imperatively and to run those threads side-by-side with well-defined critical sections.
- m_fayer 10y agoFor dead-simple parallel execution of a handful of jobs, IMO nothing beats mapping data to tasks with Linq and then "await Task.WhenAll". And if they have to share data, use something in System.Collections.Concurrent.
- emn13 10y agoFor fun bits of API inconsistency there, would you think that... "task.Wait()" is to "await task" as "Task.WaitAll(tasks)" is to "await Task.WhenAll(tasks)"? Maybe it's just me, but I sure did.
- bonzini 10y agoWhenAll returns a task (a promise, essentially) that completes "when all" its arguments have completed.
- emn13 10y agoI seem to have misremembered, the odd one out was WhenAny, and the issue is that it crashes when given the empty set, instead of waiting forever (which is fine if you're dealing with a specific number of tasks, but not fine if you're actually using it for a dynamic number of tasks). I could have sworn it was WaitAll, but heck - clearly not! Sorry :-).