21.7 Atomicity of State Change

Changing the state of a CONCURRENT system is a dangerous operation. It would be harmless if changing state could be done by an atomic operation, i.e. by an operation that cannot be interrupted. Of course, no operation can be interupted in a sequential system, i.e. state change is harmless in sequential systems. However, atomicity cannot be ensured in a concurrent system with fair scheduling of threads.

Les us assume a complex state-change-operation composed form several atomic changes. For instance, the method change in the following example provides a state change composed of at least two atomic operations:

<change>=

meth change 
  x<-@y+1  
  y<-@y+1

If the state-change is not atomic then there exists a time point where a partially changed state can be fetched by a concurrent actor, which can in turn apply state-change-operation. This may lead to a complex interleaving of partial state changes.

Consider for instance the following program where the attributes x and y of the object O should always have the same value. But this is not always true as you can observe when running the following program:

<inconsistent state change>=

declare 
class C 
   attr 
      x:0
      y:0
   meth change 
      x<-@y+1 {Time.delay 500}
      y<-@y+1
   end 
   meth test 
      try 
         if @x==@y then skip 
         else {Show 'oh weia'}
          %%%%%  raise done end
         end 
         thread {self test} end 
         {self change}
         {self test}
      catch _ then {Show stop}  
      end 
   end 
end 
 
O={New C test}