3

I know that C++ has some ways to set priority on threads. Something like what is is being discussed here. Similar to that, is there something similar available in threads that boost::asio runs? I am doing an async_read and async_write to read and write data from the network.

Note that I do want to set priority betweeen the read and write like described here in boost::asio example. I rather want to set a higher priority to the asio reader thread with respect to the whole process.

If boost::asio doesn't provide a direct mechanism to higher the priority of its thread(s), then is possible that I create the std::thread, set a higher priority to it like discussed here and provide it to asio to use it for async_read/async_write? Or is this possible with a strand?

Environment:
I am using boost 1.68 with a C++11 compiler.

AdeleGoldberg
  • 1,289
  • 3
  • 12
  • 28
  • Why do you think that boosting the priority of a process that's doing async I/O will actually be a useful thing to do? My experience – with a variety of operating systems – is that "this knob doesn't really do much." – Mike Robinson Jun 18 '20 at 15:13
  • My application has many threads. But, the asio reader thread is the most important one. Since, this is a knob available in C++, I was thinking if this was available in some way in asio as well. It remains to be tested if it helps or not but certainly worth trying from my perspective. – AdeleGoldberg Jun 18 '20 at 15:39

1 Answers1

1

I'm with the commenters that doubt this will be useful.

But to answer your question: there is no such thing as a Boost Asio thread.

It is explicitly documented why:

Threads And Boost Asio

Consequently, it is the library user's responsibility to create and manage all threads to which the notifications will be delivered.

The reasons for this approach include:

  • By only calling io_context::run() from a single thread, the user's code can avoid the development complexity associated with synchronisation. For example, a library user can implement scalable servers that are single-threaded (from the user's point of view).
  • A library user may need to perform initialisation in a thread shortly after the thread starts and before any other application code is executed. For example, users of Microsoft's COM must call CoInitializeEx before any other COM operations can be called from that thread.
  • The library interface is decoupled from interfaces for thread creation and management, and permits implementations on platforms where threads are not available.

So, you create your own threads - except the main thread I suppose - and can do so in whatever fashion you require.

sehe
  • 374,641
  • 47
  • 450
  • 633