In an earlier blog post, Intel’s Michael McCool mentioned that explicit multi-threading has serious drawbacks: Multi-threaded applications are more difficult to test than single-threaded applications and are hard to debug. The main, underlying problem with multi-threading is non-determinism, he asserts. Multiple threads running simultaneously don’t run in lockstep unless you explicitly synchronize them. However, you want to minimize synchronization because it has a negative impact on performance.
To read the full blog post, click here.
Well, from a practical point of view, life is not so simple as to say that explicit multi-threading (task parallelism) is bad because it comes along with a number of problems and data parallelism is better becaus it is a "free meal".
Agreed, there are some problems with synchronization, and they do have an impact on performance.
But it would be too simple to break it all down to performance or simplicity alone. When i write a program to acquire data from external measurement devices on a regular time base, explicit multithreading is the best way to do the job. Creating one thread for each measurement device gives the flexibility to increase the number of devices by simply creating more threads. Accellerators will not help me in this case, and there is no need to increase performance since performance just has to match the physical requirements given by the amount of data and the acquisition frequency.
Things will look completely different if you just have to mill a huge amount of data - Accellerators and automated parallism would be welcome here. But automated parallel-izing often is a trap "too huge" to use it on "small mice" - look at parallel Linq in .NET ! The necessary overhead to generate and run parallelisms there is just too much to use it on small amounts of data, even "normal" Linq is more effective in this case, let alone a simple loop construct. Automated parallelism is not necessarily more scalable than explicit multithreading, especially in terms of down-scaling. You do not have to sort 1 billion address objects every other day.
Why cause multithreading debug problems?
Why waste time?
The best way to avoid those problems is GOOD ENOUGH PRE-PLANNING before write any multithreading code.
First create table - Which one code-parts use same devices - run those code parts at different time in testqueue etc. Run in multithreading simultaneously only code parts which are using different parts of device/equipment.
Best Regards,
-Pertti-
That way leads to nightmares! Attempting to divide an application ino multithreaded and single threaded phases with synchronisation only in the former code just gets the worst of all possible outcomes. Given a choice, I'll go for slower but stable code any day...