Package org.palladiosimulator.pcm.seff

Interface ForkAction

All Superinterfaces:
AbstractAction, AbstractInternalControlFlowAction, org.eclipse.emf.cdo.CDOObject, org.eclipse.emf.cdo.common.id.CDOWithID, Entity, EObject, de.uka.ipd.sdq.identifier.Identifier, NamedElement, Notifier, PCMBaseClass, PCMClass
All Known Implementing Classes:
ForkActionImpl
public interface ForkAction extends AbstractInternalControlFlowAction
A representation of the model object 'Fork Action'.

Fork Action Splits the RDSEFF control flow with an AND-semantic, meaning that it invokes several ForkedBehaviours concurrently. ForkActions allow both asynchronously and synchronously forked behaviours.

By default, the ForkedBehaviours inside a ForkAction are asynchronous. This means that all inner ForkedBehaviours execute concurrently, but the control flow does not wait for them to terminate and continues immediately after their invocation with the successor action of the ForkAction. Thus, in this case, the ForkAction does not wait for any inner ForkedBehaviour. It is furthermore not possible to refer to results or output parameters of asynchronously ForkedBehaviours in the rest of the RDSEFF, as it is unclear when these results will be available.

To model synchronization, a SynchronizationPoint can be added to the ForkAction. Then, all ForkedBehaviours within the SynchronizationPoint execute concurrently and the control flow waits for each of these behaviours to terminate before continuing. If a SynchronizationPoint is used, the ForkAction blocks and waits for all ForkedBehaviours inside the SynchronizationPoint before continuing. Thus, in this case, the successor action of the ForkAction is only executed after all ForkedBehaviours inside the SynchronizationPoint have completed execution. Component developers can specify a result of the computations with its attached VariableUsages.

Each ForkedBehaviour can be considered as a program thread. All parameter characterisations from the surrounding RDSEFF are also valid inside the ForkedBehaviours and can be used to parameterise resource demands or control flow constructs. The parameter characterisations are the same in each ForkedBehaviour.

The same Fork Action can contain asynchronous and synchronousForkedbehaviours at the same time. In that case, all forked behaviours are started. The control flow waits for all synchronous behaviours to finish execution and only then continues.

The following features are supported:

See Also:
Generated class or method.
EMF model class or method.