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. The following listing, presents DeuceStepFactory class as an implementation of the IStepFactory.

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.

We also provide the JWormBenchApp application that gives an easier way to parameterize and run a JWormBench’s workload using the default implementations of the mentioned abstract types. By default JWormBenchApp uses a Guice module (a java class that contributes configuration information - bindings), that specifies the default implementations for all abstract types. Then each synchronization strategy must define its own Guice module overriding bindings that should provide implementations with a distinct behavior. For instance, a Guice module to configure Deuce STM just have to define the binding for IStepFactory type. On the other hand, a Guice module for JVSTM must define IStepFactory and INodeFactory bindings as shown in the following listing.

public class JvstmSyncModuleextends AbstractModule{
  @Override
  protected void configure(){
    bind(IStepFactory.class)
      .to(JvstmStepFactory.class)
      .in(Singleton.class);
    bind(INodeFactory.class)
      .to(JvstmBenchNodeFactory.class)
      .in(Singleton.class);
    }
  }
}