"Concurrent Whiteboard"

Goals

Parallel experiment frameworks require a robust memory model for event and non-event data. It should allow the concurrent and conflict free access of independent processing units ('algorithms') to data items they depend on. The information about data vs. algorithm dependencies will as well be an input to underlying parallel scheduling mechanisms. This single memory model is called 'concurrent whiteboard'. All states involved in the processing inside the algorithms should be managed by this whiteboard.

Requirements to concurrent whiteboard

Multi-event data store
The life time and validity of data items is given by the 'context' in which the algorithms are executed
Data items are identified by type, an id and the context
Allowed transactions could be get, put and update

Requirements to algorithms

Re-entrant w.r.t. to different contexts, i.e. free of states connected to the aforementioned 'context'
To be carried out transactions and their dependencies are declared upfront

Requirements to scheduler

The concurrent whiteboard contents + declared data dependencies + knowledge about reentrancy should be sufficient to know when an algorithm can be run
Details of actual execution could be left to e.g. libdispatch

Plans until May

Lay out a full API covering the proposed design concepts
Implement this API and combine it with existing prototypes developed in LHCb (by Markus Frank)
Use common tests and metrics from “Evaluation of Frameworks” demonstrator