[EMA CPP] Trade Safety of a class that inherits from OmmConsumerClient
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.
Best Answer
-
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.
0
Answers
-
Hi @cdefusco,
With ApiDispatch mode, the three callback methods; onRefreshMsg, onUpdateMsg, onStatusMsg are invoked by EMA thread. You may need to add a lock for your list or map objects in case that they are accessed by other threads.
0 -
Ok, so two or more consequent call of onRefreshMsg, for example, are however thread safe, right?
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛