Ch4, Ex11

It happens because the way the expression (X+Y)+Z is evaluated by oz implementation. It'll actually compute (X+Y)+Z by doing following:

local T R in
   T=X+Y
   R=T+Z
   {Browse R}
end 

Now T=X+Y immediately needs X and Y, {MakeX} and {MakeY} are called immediately which in turn print x, y. Need for Z arises only when execution reaches R=T+Z (which is after ~6 secs due to the explicit delay in MakeY) and hence z is printed only after ~6 secs. Now MakeZ also puts in explicit delay of 9 secs so R is only evaluated in 9+6=15 seconds.

Time Taken can be measure by following:

declare
fun lazy {MakeX} {Browse x} {Delay 3000} 1 end
fun lazy {MakeY} {Browse y} {Delay 6000} 2 end
fun lazy {MakeZ} {Browse z} {Delay 9000} 3 end
X={MakeX}
Y={MakeY}
Z={MakeZ}

local T1 T2 in
   T1 = {Property.get 'time.total'}
   %CHANGE HERE
   %{Browse thread X+Y end +Z}
   {Browse (X+Y)+Z}
   T2 = {Property.get 'time.total'}
   {Browse 'timeTaken:'#(T2-T1)}
end 

For non-concurrent version it takes about 15 secs while for the concurrent version it takes around 9 secs(because Max of all explicit delays is 9 secs in MakeZ).

From above results it may seem that we should always use concurrency for adding integers but that is not true because here the evaluation of x, y and Z takes some time due to explicit delay but in adding simple integer values its practically 0 and if we then use concurrent version then we're unnecessarily burdening our program with thread management overhead and also spoiling the program structure.