channel’s buffer pool access

LtDoolittle6

Hello
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.

DevTrev

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.