Extending JWormBench

Each synchronization strategy must provide a concrete implementation of the IStepFactory interface, whose instances are responsible for creating a collection of step objects, based on the information gathered from an iterable IStepSetup instance (the default implementation of IStepSetup loads step data from a configuration file). The easiest way of providing an implementation of the IStepFactory interface is by extending the AbstractStepFactory class, according to the factory method design pattern.

public class DeuceStepFactory extends AbstractStepFactory{
  public DeuceStepFactory(...){
	super(stepSetup, opFac);
  }
  protected IStep factoryMethod(IOperation<?>op,...){
	return new AbstractStep(direction,op){
	  @Override
	  public Object performStep(IWorm worm){
		Object res = performAtomicOperation(worm);
		performmAtomicMove(worm, direction);
		return res;
	  }
	  @org.deuce.Atomic
	  Object performAtomicOperation(IWorm worm){
		return op.performOperation(worm);
	  }
	  @org.deuce.Atomic
	  void performAtomicMove(IWorm worm,...){
		worm.move(direction);
		worm.updateWorldUnderWorm();
	  }
	};
  }
}

Depending on the STM implementation, it may be required to provide other implementations of the JWormBench core entities, such as world, node, or coordinates, among others. For instance, in JVSTM the fields accessed in the context of a transaction must be of the VBox type. In the case of JWormBench this means that the value field of node must be of the VBox type. So, the configuration of JVSTM for JWormBench must provide also an implementation of a node's factory - an implementation of INodeFactory interface.