[EMA CPP] Trade Safety of a class that inherits from OmmConsumerClient

cdefusco

Hi, suppose I have a class that inherits from OmmConsumerClient:

class Client : public thomsonreuters::ema::access::OmmConsumerClient
{
public:
    Client();
    ~Client();
    void onRefreshMsg(const thomsonreuters::ema::access::RefreshMsg&, msg, const thomsonreuters::ema::access::OmmConsumerEvent& event);
    void onUpdateMsg(const thomsonreuters::ema::access::UpdateMsg& msg,const thomsonreuters::ema::access::OmmConsumerEvent& event);
    void onStatusMsg(const thomsonreuters::ema::access::StatusMsg& msg, const thomsonreuters::ema::access::OmmConsumerEvent& event);
};

Now suppose that in one or all of the three methods onRefreshMsg, onUpdateMsg, onStatusMsg I have a list or a map readed and writed in a concurrent way (in others words a critical section). Suppose also that I use the thread of EMA library to dispatch the message for these three callback and not a my own thread (using the OmmConsumerConfig::ApiDispatchEnum).

In this scenario, each critical section (as: lists, maps and so on) must to be locked, for example using a mutex/spin lock? Or the call is made in a thread safe way by EMA library?

For example two call of onRefreshMsg for different notification will be thread safe? or there will be an interleaving giving a race condition for structures managed in the method onRefreshMsg?

Thank you.

umer.nalla

Hi @cdefusco

Each instance of the OmmConsumer will only call one instance of onRefresh/onUpdate/onStatus from the same API thread at a time.

As events (such as Refresh / Update / Status) arrive from the server they are stored in an internal queue. The API thread reads each event from the queue one at a time and calls the appropriate event handler. Once your event handler returns control, the API will then read the next event from the queue and call the event handler and so on..

So, even if you have subscribed to multiple RICs, the single instance of OmmConsumer will only call one event handler at a time.

You can read section 2.4 of the EMA Developer Guide for more information.