feo and lola

[ramceb]

[LittleHuba]

Initial proposal:

Problem statement

The fixed execution order framework (FEO) in S-CORE requires stable sample data over the full execution of a task chain to support reprocessing.
This means, at the start of the task chain data from a publisher outside of FEO is "retrieved" and only this data may be used throughout the task chain.
A task chain may span multiple processes.

This concept can be compared to a snapshot mechanism.
At the beginning of a task chain a snapshot is created and any activity within the task chain only works on data from this snapshot,
fully ignoring older/newer data.
FEO uses so-called service activities to perform this snapshot of the data.

Trivial approach

Without much thought, one might choose to let the service activity retrieve the data from the original producer and provide it with its own service offer
to all following activities within the task chain.
The snapshot is done by using a separate communication channel fully under the control of FEO.
This comes with the drawback, that it renders a zero-copy communication unfeasible, since the service activity must copy the data from the original shared
memory object of the Proxy to the shared memory object of its Skeleton.

Zero-copy capable approach

To provide a snapshot feature with zero copy in mind, a more sophisticated approach is necessary.
The main difficulty lies in task chains potentially spanning multiple processes.

With that in mind, the original problem statement can be generalized to:
If process A holds a SamplePtr to a specific sample, there must be a way to reliably create a SamplePtr to the same sample in a process B.

The straight-forward solution would be to allow process A to send the sample pointer to process B.
This raises certain questions:

• What if process B is not allowed to access the shared memory object containing the sample?
• How would we handle the reference counting for SamplePtrs?
• What if process B already holds max-sample-count SamplePtrs for this event?

Finding a solution to these questions is difficult. Therefore, we propose a different approach.
Instead of directly forwarding the SamplePtr to another process, we enable other processes to recreate it with their own proxy.

For this we introduce the SamplePtrHandle. This handle does not allow direct access to a sample.
Instead it can be used with a ProxyEvent to create a SamplePtr using a new API GetSample().

For this API, the same restrictions apply as for the GetNewSamples() API.
Meaning, it can only be used on subscribed events and as long as the application does not exceed its max-sample-count for this event.

Further, calling GetSample() has no impact on the behavior of GetNewSamples().
E.g., a call to GetNewSamples() may retrieve the same sample, previously retrieved with GetSample().

Formalized APIs

SamplePtr

SamplePtrHandle SamplePtr<T>::GetHandle() const

The API GetHandle() of the SamplePtr class returns a SamplePtrHandle.
This handle is only guaranteed to remain valid as long as the SamplePtr on which GetHandle() was called remains alive.

The SamplePtrHandle contains:

• the ElementFqId
• the slot index
• the timestamp

It can not be constructed by the user and may only be retrieved using the above API.
It may be copied and moved.

ProxyEvent

bmw::Result<SamplePtr<T>> ProxyEvent<T>::GetSample(const SamplePtrHandle&)

For a given SamplePtrHandle, GetSample() returns the corresponding SamplePtr, iff:

1. The ElementFqId in the SamplePtrHandle matches the ElementFqId of the ProxyEvent on which GetSample() is called, and
2. The ProxyEvent has been successfully subscribed at least once, and
3. The slot index in the SamplePtrHandle is within the bounds of slots, and
4. The indexed slot is valid and not in writing, and
5. The timestamp of the slot matches the timestamp in the SamplePtrHandle, and
6. The application holds less SamplePtrs for this ProxyEvent than its configured max-sample-count

In all other cases a corresponding error is returned.

Usage in FEO

The task chain is started by the service activity that retrieves the SamplePtrs for all relevant samples.
It stores these pointers for the full duration of the task chain.
Service activities communicate the SamplePtrHandles to dependent activities.
These activites have their matching Proxies to transform the received SamplePtrHandles back to SamplePtrs.

With those proxies the activities call GetSample() to retrieve the actual data.
Since the service activity holds the SamplePtrs throughout the full task chain, it is guaranteed, that every activity can access the same samples.

At the end of the task chain the service activity is scheduled once more to release the the SamplePtrs.

For communication within a task chain, the normal communication scheme (using GetNewSamples()) can be used.