Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

TPL abstracts threads away, but not mutable shared memory, nor any primitives used to synchronize access to such from concurrent tasks.


TPL (and PLINQ) raise the level of abstraction. They discourage the use of mutable shared memory and low-level locks. They encourage the use of immutable or thread-safe data structures.

Joe Duffy, who had originally done quite a bit of initial work on the TPL, argues in favor of this paradigm[0] of raising the abstraction level.

I feel like introducing the low-level tools without providing a raised abstraction level may be beneficial in the long run (you need low-level tools to build high-level abstractions), however, without these abstractions I suspect a generation of JS developers will need to re-learn all the multi-threading lessons of the last few decades.

[0]: http://joeduffyblog.com/2016/11/30/15-years-of-concurrency/


I don't see how TPL discourages the use of mutable shared memory any more so than a simple thread pool. Note: I'm not saying that it's not a higher level of abstraction, only that it's abstraction in a different direction (the one that has nothing to do with sharing or mutability).

I'm not surprised that TPL author discourages mutable shared memory and locks - this is the conclusion to which anyone dealing with concurrency a lot arrives sooner rather than later. But that's orthogonal to TPL design.

Now, PLINQ does attack the whole mutable shared memory thing head-on. But it's a much higher level of abstraction on top of TPL.


We have the great benefit of stewards having already learned those lessons.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: