Each run of each test produces some outcomes in a certain running time. We define productivity as the ratio of the number of outcomes produced by the running time of the testing program. By summing outcomes counts and times, productivity is easily defined on multiple runs of series of tests. We view productivity as a decent estimate of the efficiency of a very particular application: testing machines.

The following diagram shows total productivity of the mixed tests (Part II, written X below) and of their synchronised versions F (fences), A (atomic reads and writes), P (protected reads, PPC only) and L (locks), for our five machines power7 (Power 7), abducens and vargas (Power 6), chianti and saumur (X86).

Notice that adding synchronisation constructs, as offence does, does does not impact directly all the code whose runing time is measured: test programs include test harness code, which remains unchanged. Nevertheless, inserting synchronisation constructs has noticeable impact on the running time of test programs, especially for locks (mapping L) whose usage divides productivity by roughly a factor of two on Power machines.

The other mappings F, A and P induce a slight loss of efficiency, with respect to unsynchornised tests. With due precaution, given that our efficiency measure apply to one particular “application” (testing machines), we may remark:

• For Power (power7, abducens and vargas, fences (F) look like the are the more efficient way to restore SC.
• The situation is less clear for X86 (chianti and saumur): fences (F) and atomic writes (A) are two means to restore SC of similar efficiency.