8 Simple Rules for Desiging Threaded Applications

archive development-discussion-jme2
1

I cam across this add a while back and figured i would post it here

Clay Breshears wrote:

Introduction


The Threading Methodology used at Intel has four major steps: Analysis, Design & Implementation, Debugging, and Performance Tuning. These steps are used to create a multithreaded application from a serial base code. While the use of software tools for the first, third, and fourth steps is well documented, there hasn
2
Continued wrote:
Rule 6. Never assume a particular order of execution.


With serial computations, it is easy to predict the statement that will be executed following any other statement in a program. On the other hand, thread execution order is non-deterministic and controlled by the OS scheduler. What this means is that there is no reliable way of predicting the order of threads running from one execution to another or even which thread will be scheduled to run next. This is done primarily to hide execution latency within an application, especially when run on a system with fewer cores than threads. If a thread blocks because it needs memory that is not located in cache or to process an I/O request, the scheduler will swap out the blocked thread and swap in a thread that is ready to run.

Data races are a direct result of this scheduling non-determinism. If you assume that one thread will write a value into a shared variable before another thread will read that value, you may be right all of the time or you may be right some of the time or you may be right none of the time. Sometimes, if you
3

Rule 2 is kinda silly, the author even admits it. Sometimes you can very easiliy make very big speedups by focusing on hotspots. Escp in the >2 core world, that could help you a lot more compared to putting different high level systems in different threads.