How MAIN_THREAD_MODEL vs. SINGLE_THREAD_MODEL works?

Problem:

• Product Name: VisiBroker
• Product Version: 6.x and later
• Product Component: ORB

How MAIN_THREAD_MODEL vs. SINGLE_THREAD_MODEL works?

Why MAIN_THREAD_MODEL is slower than SINGLE_THREAD_MODEL?

Resolution:

The MTM ("MAIN_THREAD_MODEL") is really different from STM ("SINGLE_THREAD_MODEL") in a way that the main thread dispatcher which upon accepting an incoming connection, it does not create threads to execute requests from the connection. Instead it just stores the connection in a list.

Whereas, STM policy still uses the thread pool dispatcher except "...all up calls made by this POA to implementation code (servants and servant managers) are made in a manner that is safe for code that is multi-thread-unaware...." (from OMG Thread Policy specification). Beside this difference, the rest of STM works like the default ORB_CTRL_MODEL.

It does not matter how many POA instances.

For MTM, all requests coming on a connection will be queue and poll for processing using perform_work() or run() one by one.

For STM or ORB_CTRL_MODEL(default), each request on a connection will be serviced by each thread concurrently. If a box contains 16 cpus and only the VisiBroker server is running, potentially 16 requests can be serviced at the same time. If each request is independent of each other, the performance result is even more efficient. However, the STM POA ensures that the actual up calls to the implementation code are processed sequentially, hence these calls are safe for code that is multi-thread-unaware.

For MTM, there will be one thread listening on the connections, and only one thread to service the requests coming from the connections. The service thread will cycle through all the connections and processed the request one by one upon receiving the call from ORB::perform_work().

For both STM & OCM, there will be a listening thread and a thread pool dispatcher will be sending worker for performing on the requests coming from all the connections in any order irregardless on the number of POA instances activated within the application. Depending on workload, the worker will create more threads or reduce it accordingly for better management of resources.

Don't be misled by the policy name defined by OMG. Though STM is named single thread, this does not really mean only one thread is used to service the requests. STM uses the same request thread pooling as OCM with the only exception when certain function entry is called on the STM POA, pre_invoke for example, will be mutually exclusive to other threads, for code that is multi-thread-unaware.

For STM the "threadMax=1" property is not necessary.

"threadMax" property value does not mean an absolute total count of systems threads. The total threads count in the thread pool goes something like "threadMax" plus current number of connections.

So, setting "threadMax=1" is almost equivalent of saying one service thread per connection. Whereas for MTM there is always only one service thread for N number of connections.

As summary MTM is slower than STM.