diff options
Diffstat (limited to 'Examples/threaded_example.txt')
| -rw-r--r-- | Examples/threaded_example.txt | 108 |
1 files changed, 108 insertions, 0 deletions
diff --git a/Examples/threaded_example.txt b/Examples/threaded_example.txt new file mode 100644 index 000000000000..1e41a0ef2ed9 --- /dev/null +++ b/Examples/threaded_example.txt @@ -0,0 +1,108 @@ +The following is a demonstration of the threaded.d script, + + +Here we run a test program called "cputhread" that creates 4 busy threads +that run at the same time. Here we run it on a server with only 1 CPU, + + # threaded.d + + 2005 Jul 26 02:56:37, + + PID: 8516 CMD: cputhread + + value ------------- Distribution ------------- count + 1 | 0 + 2 |@@@@@@@ 17 + 3 |@@@@@@@@@@@ 28 + 4 |@@@@@@@@@@@ 27 + 5 |@@@@@@@@@@@ 28 + 6 | 0 + [...] + +In the above output, we can see that cputhread has four busy threads with +thread IDs 2, 3, 4 and 5. We are sampling at 100 Hertz, and have caught +each of these threads on the CPU between 17 and 28 times. + +Since the above counts add to 100, this is either a sign of a single CPU +server (which it is), or a sign that a multithreaded application may be +running "serialised" - only 1 thread at a time. Compare the above output +to a multi CPU server, + + + +Here we run the same test program on a server with 4 CPUs, + + # threaded.d + + 2005 Jul 26 02:48:44, + + PID: 5218 CMD: cputhread + + value ------------- Distribution ------------- count + 1 | 0 + 2 |@@@@@@@@@@@ 80 + 3 |@@@@@@@@@@ 72 + 4 |@@@@@@@@@ 64 + 5 |@@@@@@@@@@@ 78 + 6 | 0 + [...] + +This time the counts add to equal 294, so this program is definitely +running on multiple CPUs at the same time, otherwise this total would +not be beyond our sample rate of 100. The distribution of threads on CPU +is fairly even, and the above serves as an example of a multithreaded +application performing well. + + + +Now we run a test program called "cpuserial", which also create 4 busy +threads, however due to a coding problem (poor use of mutex locks) they +only run one at a time, + + # threaded.d + + 2005 Jul 26 03:07:21, + + PID: 5238 CMD: cpuserial + + value ------------- Distribution ------------- count + 2 | 0 + 3 |@@@@@@@@@@@@ 30 + 4 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 70 + 5 | 0 + [...] + +The above looks like we are back on a single CPU server with 100 samples +in total, however we are still on our 4 CPU server. Only two threads have +run, and the above distribution is a good indication that they have +run serialised. + + + +Now more of a fringe case. This version of cpuserial again creates 4 threads +that are all busy and hungry for the CPU, and again we run it on a 4 CPU +server, + + # threaded.d + + 2005 Jul 26 03:25:45, + + PID: 5280 CMD: cpuserial + + value ------------- Distribution ------------- count + 1 | 0 + 2 |@@@@@@@@@@@@@@@ 42 + 3 |@@@@@@@@@@@@@@@@@@ 50 + 4 |@@@@@@ 15 + 5 |@ 2 + 6 | 0 + [...] + +So all threads are running, good. And with a total of 109, at some point +more than one thread was running at the same time (otherwise this would +not have exceeded 100, bearing in mind a sample rate of 100 Hertz). However, +what is not so good is that with 4 CPUs we have only scored 109 samples - +since all threads are CPU hungry we'd hope that more often they could +run across the CPUs simultaneously; however this wasn't the case. Again, +this fault was created by poor use of mutex locks. + |