Skip to content

SO 5.6 Tutorials TrickyThreadPool Intro

Yauheni Akhotnikau edited this page Sep 5, 2019 · 2 revisions

The task

In that mini-serie we'll discuss the creation of custom dispatcher for SObjectizer and several related things.

This example has roots in a story told by one of SObjectizer's users. He used SObjectizer for managing devices attached to a PC. On the start of the work, all devices should be initialized. An initialization of one device takes some time (somewhat about a second or two). When a device is initialized it will be read and written by the application. These IO-operations have performed asynchronously and take much less time than the initialization procedure. When a device is used for a long time the reinitialization of the device can be necessary. The reinitialization procedure is a synchronous operation and takes some time (comparable with the duration of the initialization). From time to time a device can be detached from the PC and reattached again. In that case, the reattached device should be initialized again.

All the described operations are stateless and because of that, the user used just one agent with thread-safe handlers bound to an instance of adv_thread_pool dispatcher. But this approach had a drawback: at the start of the application, there were many requests for initialization of a device. So all threads from adv_thread_pool dispatcher were busy handling init requests. And io_op requests had to wait in the queue. The more devices attached and the longest initialization duration the more time are spent by io_op requests in the queue.

In this example, we'll discuss a simulation that shows the case described above and the solution in the form of the custom dispatcher that has priority handling of io_op requests.

The content

The description of the example contains several parts:

The example's source code

The source code of the described example can be found in a separate repository: so5_tricky_thread_pool_disp_en.

Clone this wiki locally