channel’s buffer pool access
everyone,
I am developing NI provider utilizing UPA C API and have a question about
accessing channel’s buffer pool in multi-threaded environment.
Basically I want to parallelize messages encoding between several threads,
and write them sequentially in another one.
If transport locking model is RSSL_LOCK_NONE, is it necessary to
synchronize rsslGetBuf and rsslReleaseBuf with the rest of the API (mostly I
am talking about its I/O part)?
Is transport locking model regulates only transport(I/O) part of the RSSL
environment or channel’s buffer pool as well?
I’d appreciate any info that would help to answer the question.
Thanks.
Best Answer
-
The sharedPoolLock option in rsslBindOpts is used to selectively turn on locking for the shared buffer pool on an RsslServer. For NI Provider connections, this is not used, since the RsslChannel created by RsslConnect does not have an associated RsslServer shared buffer pool. In this case, the channel locking will fulfill the same role, providing thread safety when calling any RsslChannel operations.
To answer your original questions:
>Is transport locking model regulates only transport(I/O) part of the RSSL environment or channel’s buffer pool as well?
The locking model regulates all RSSL calls. If RSSL_LOCK_GLOBAL is set, any actions that involve creation or destruction of the channels will be thread safe. However, any usage of the channels(i.e. calls to rsslRead, rsslWrite, or rsslGetBuffer) will not be thread safe. If a multithreaded application is accessing a given RsslChannel with multiple threads for reading or writing, it is recommended to use the RSSL_LOCK_GLOBAL_AND_CHANNEL option instead of manually locking around the functions.
However, if the application is using the RsslChannel’s reading and writing operations in a single-threaded manner-i.e. one thread to get buffers, encode and write to the wire and one thread to read and decode from a given RsslChannel- there should not be any thread contention, so RSSL_LOCK_GLOBAL or RSSL_LOCK_NONE can be used. RSSL_LOCK_NONE should only be used if a single thread is creating and destroying channels, in addition to the above use case.
From the use case specified in the original email(multiple threads encoding, with a single thread writing to the wire), if multiple encoding threads are calling RsslGetBuffer, I would recommend using RSSL_LOCK_GLOBAL_AND_CHANNEL.
>If transport locking model is RSSL_LOCK_NONE, is it necessary to synchronize rsslGetBuf and rsslReleaseBuf with the rest of the API (mostly I am talking about its I/O part)?
Yes. Any RsslChannel function calls will need to be locked around if locking is turned off. In addition, the creation or deletion of any channels will need to be locked around.1
Categories
- All Categories
- 6 AHS
- 37 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
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛