Correct Use of Multithread Mode in Rogue Wave Server Applications
Rogue Wave® Server is designed to benefit from the multithreading capabilities of its environment to optimize the task of sending messages over the network, which is the most time-consuming. (See
Sending Requests in Multithread Mode). Any other use of threads in an Rogue Wave Server application should be undertaken only with the utmost precautions.
A typical Rogue Wave Server application is made of the following threads:
a main thread that runs the main loop: the main loop receives requests from the components, processes updates on server objects, and executes notification cycles.
one thread per component if sending-thread mode is used. This thread is managed by Rogue Wave Server to stream and send messages to the communication layer.
Generally speaking, the API of Rogue Wave Server is not multithread-safe. Any applicative thread that accesses the server model and other server objects should interact with the Rogue Wave Server API under the protection of a mutex. An applicative thread must not manipulate the server model while the main thread is processing a component request or executing a notification cycle. If this rule is not respected, it may lead to weird crashes and inconsistency due to unprotected multithreaded access to the memory shared by Rogue Wave Server and the applicative thread.
The application model implemented by Rogue Wave Server modeling services is not multithread safe. Any access to an entry or to a relation from an applicative thread while the main thread is performing a notification cycle is a source of conflicts. A typical Rogue Wave Server application perform the following steps
loop {
select(<a set of socket corresponding to component connections>);
processRequest(soc);
}
Rogue Wave Server decodes the incoming request, processes it, and triggers a notification cycle. Before and after any request received from the select instruction is processed, the server application calls the methods IlsMvProcess::beforeRequest and IlsMvProcess::afterRequest. You may want to use tese methods to take and release a global mutex shared by several applicative threads that must interact with the Rogue Wave Server API.
Another mechanism can be used to manage interaction of applicative threads with the main thread: the loopback mechanism implemented by the IlsTcpLoopback class. This class enables communication between an applicative thread and the main thread. An applicative thread can post a portion of code to be executed by the main thread.
Generally speaking, the main bottleneck of an Rogue Wave Server application is the time spent sending data over the network. The impact of this task is greatly minimized by the use of the sending-thread mode, which is automatically managed by Rogue Wave Server.
Version 6.3
Copyright © 2018, Rogue Wave Software, Inc. All Rights Reserved.