Introduction

Release 4.4 of the Caplin Platform introduced a major new feature and an important pre-requisite for components that sit within the platform.

Prior to 4.4, all DataSource messages were serviced on a single thread and callbacks could be guaranteed to occur only on a single thread. With 4.4, multiple threads service DataSource messages, with the result that callbacks can occur on more than one thread and that more than one callback may be in progress at any point in time.

This has important consequences for any software (such as Transformer Modules) that process the raw datastream:

Functions that are implemented should be reentrant.
Any data structures within modules should be threadsafe.
The compiler flags should include =-D_REENTRANT= which will cause thread-safe functions to be linked on certain platforms.

The following features often make code non-reentrant:

Holding static data over successive calls
Returning a pointer to static data

The following features often make data structures non-threadsafe:

Sharing global data between threads and
Modifying global data without using any synchronisation methods
Inappropriate usage of synchronisation methods.

There are many documents detailing threadsafe and reentrant programming techniques, if you are at all uncertain we recommend that you consult them.

Caplin Transformer Threading

The Transformer aims to be totally thread-safe and reentrant, permitting multiple updates to be processed by the system concurrently. In order to maximise performance, it's desirable that the interface between the Transformer and loaded modules permits the concurrent processing of updates.

Due to a desire to support modules written using older versions of Transformer, 4.4 introduces a new API for subscription management which brings benefits regarding making wildcard subscriptions explicit and providing finer grained control over where the requested data should be source from.

Modules written using the new API, should accept the contract that their callbacks may well be called concurrently, including the case (which may arise dependending on configuration) that two updates may need to be processed at the same time.

The old API is available to use, however it has been marked as deprecated due to the performance impact that the usage of this API will imply:

The callbacks specified will not be entered concurrently
The callbacks will occur only on a single thread.

Guaranteeing these contracts implicitly creates synchronisation points that can quite seriously reduce performance.

DSDK Interaction - Events

Handling of timed events has changed, please see events for details on how to use events within a multi-threaded environment.