Delphi XE7: The new Tasks / Parallel Computing Library. Like any library, it is not a magic bullet!
Posted by jpluimers on 2015/01/01
In Delphi XE7, Embarcadero introduced a new Parallel Computing Library.
Programmers – human as they are – see this as a silver bullet, thinking using such a library will take away all your performance issues without having to know about solving race conditions.
Boy are they wrong. The library helps you, and makes it easier. Easier in the sens of “less hard”.
So here is my friendly warning:
Parallel programming is hard. Live with it.
This apart from another important warning:
Delphi XE7 is the first version where this library is introduced. So expect bugs and more bugs.
This isn’t to say you should not use a library for parallel computing (the OmniThreadLibrary has been around for a reason), just that it is hard to get these right, even for library writers. They often get it right better and faster than rolling your own.
Remember Delphi 6 when TMultiReadExclusiveWriteSynchronizer was introduced and how long it took to flesh out the bugs there?
So here is my last warning:
Parallel computing is that hard. So do use a library, and do so with care. Favour established libraries over new ones.
Then learn to think in the way parallel code works: as much code that can run independently from each other without having to wait. Then learn about how to decouple things (so there is no state, and information can get passed around without the need to wait, i.e. in an asynchronous way).
Thanks to Uwe Raabe, Simon Stuart and Stefan Glienke for reminding me about the first and learning about the second:
- New programmers are drawn to multithreading like moths to flame, with similar results.
- Transforming an algorithm to a parallel solution can make it slower unless you get partitioning right.
This is copied from the New Features (the link is for the youngest Delphi, so when XE8 comes out, it will have different content):
Parallel Computing Library
- The Parallel Computing library helps you exponentially increases performance making it easier to write multi-threaded applications that take advantage of multi-core CPUs
- Boost the performance of your existing VCL and FireMonkey applications, with a self-tuning thread pool
- Include the new System.Threading unit in your apps and you can do the following:
- Parallel ‘for’ loops
- Scheduling of tasks
- Futures
- Joining of multiple tasks and waiting for all to complete
- Easy integration for a significant performance boost
–jeroen
via
PS: What a coincidence: Nick Hodges: Man, the chapter on Multi-threading is going to be seriously hard to write..
The Wiert Corner - irregular stream of stuff 
Sir Rufo said
expect bugs like http://stackoverflow.com/q/27754399/1744164
jpluimers said
Thanks. Added to the post.
Petar said
Too much bugs I’d say. Embarcadero should have done more extensive tests before releasing PPL in a commercial product. Anyway – good start :)
Rick said
Yep!
SpeedFreak said
Good points.
I’ve always found that if someone thinks threading will make a problem easier to solve, then they haven’t fully understood the problem.
TMultiReadExclusiveWriteSynchronizer was introduced in Delphi 4 but got a bad rep because the majority of people didn’t understand the inherent danger of read-to-write lock promotion. Unfortunately one of these were Danny Thorpe and late in the D6 beta he completely rewrote the class (and completely broke lock promotion among other things). We’re still using the D5.01 version of TMultiReadExclusiveWriteSynchronizer in several of our systems and it works just fine.