org.multiverse.stms.alpha.commute.html Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of multiverse-alpha-unborn

Contains the main Multiverse STM Implementation: the Alpha Engine. The Alpha engine supports readonly and update transactions. It also supports the retry/or else mechanism. This not the jar you want to have in your final distribution because it isn't instrumented (hence the name unborn). The jar you eventually want to have in your distribution is the multiverse-alpha jar. What this package does, is test the instrumentation for the Javaagent. The compiletime instrumentation is tested in the multiverse-alpha package (where all tests are copied and reexecuted but now with compiletime instrumentation).

The newest version!




Commute

Operations can be executed in a different order, while still being valid.
For example an unconditional increase of the salary or an increase in the size.

Another example is a change in the size of a collection. If somehow an operation
could commute, so in case of a conflict reexecuted,

CommuteTask... or perhaps using annotation.

    public void add(E item){
        head = new Node(head, item);
        incSize();
    }

    @Commute
    void incSize(){
        size++;
    }


Needed

    Maintain a history with all commute operations
    


When a transaction fails, it should check if the fields in that conflict are fields
changed in a commute operation; this is part of the transaction history.

The prepare using commute works like this:

    
        It automatically should revert the fields that can be 'repared'. The other fields
        should not be changed. The problem is that somehow needs to be analyzed wich fields
        should be copied; could the orelse functionality save us somehow? So can this
        functionality somehow in it.
    
    >
    
        The commute operations should all re-execute.
    



There also needs to be a change/addition to the current conflict detection. Atm
is is failfast because there is no possibility to repair, but if the repair is added
we need to find all fields from all atomic objects that have conflicted. Based on
this conflicting fields one can detect which commute methods need to be notified.

Commute matchers;
Can automatically all commuters be invoked?