11

This is somewhat related to this question, but I think I need to know a little bit more. I've been trying to get my head around how to do this for a few days (whilst working on other parts), but the time has come for me to bite the bullet and get multi-threaded. Also, I'm after a bit more information than the question linked.

Firstly, about multi-threading. As I have been testing my code, I've not bothered with any multi-threading. It's just a console application that starts a connection to a test server and everything else is then handled. The main loop is this:

while(true)
{
    Root::instance().performIO(); // calls io_service::runOne();
}

When I write my main application, I'm guessing this solution won't be acceptable (as it would have to be called in the message loop which, whilst possible, would have issues when the message queue blocks waiting for a message. You could change it so that the message-loop doesn't block, but then isn't that going to whack the CPU usage through the roof?)

The solution it seems is to throw another thread at it. Okay, fine. But then I've read that io_service::run() returns when there is no work to do. What is that? Is that when there's no data, or no connections? If at least one connection exists does it stay alive? If so, that's not so much of a problem as I only have to start up a new thread when the first connection is made and I'm happy if it all stops when there is nothing going on at all. I guess I am confused by the definition of 'no work to do'.

Then I have to worry about synchronizing my boost thread with my main GUI thread. So, I guess my questions are:

  1. What is the best-practice way of using boost::asio in a client application with regard to threads and keeping them alive?
  2. When writing to a socket from the main thread to the IO thread, is synchronization achieved using boost::asio::post, so that the call happens later in the io_service?
  3. When data is received, how do people get the data back to the UI thread? In the past when I used completion ports, I made a special event that could post the data back to the main UI thread using a ::SendMessage. It wasn't elegant, but it worked.

I'll be reading some more today, but it would be great to get a heads up from someone who has done this already. The Boost::asio documentation isn't great, and most of my work so far has been based on a bit of the documentation, some trial/error, some example code on the web.

Community
  • 1
  • 1
Moo-Juice
  • 38,257
  • 10
  • 78
  • 128

4 Answers4

6

1) Have a look at io_service::work. As long as an work object exists io_service::run will not return. So if you start doing your clean up, destroy the work object, cancel any outstanding operations, for example an async_read on a socket, wait for run to return and clean up your resources.

2) io_service::post will asynchronously execute the given handler from a thread running the io_service. A callback can be used to get the result of the operation executed.

3) You needs some form of messaging system to inform your GUI thread of the new data. There are several possibilities here.

As far as your remark about the documention, I thing Asio is one of the better documented boost libraries and it comes with clear examples.

André
  • 460
  • 6
  • 18
  • thanks for your response. When you say there are several possibilities, what are the ones you have used in the past? – Moo-Juice Jan 19 '11 at 14:11
  • @Moo-Juice, I've not been in a situation where there was one specific GUI thread which needed to handle the data. I just used the callback mechanism and handle the data from an io_service thread as it came in. Some form of message queue which the gui threads reads, could be used to indicate the arrival of new data. Or you could simply use a conditional variable. Realy depends on you application, design and requirements. – André Jan 20 '11 at 08:55
  • thanks for the advice. I've got it working nicely and also used strands to synchronise some timings. All I have to do is now wrap up some delegates in to ::SendMessage() so they aer invoked on the GUI thread and I should be set. Thanks for your help, and `io_service::work` did the trick nicely! – Moo-Juice Jan 20 '11 at 09:21
  • @Moo-Juice, one thing to keep in mind when using strands. If access to a resource needs to be guarded. Make sure to do all access to that resource through the io_service, wrapped in the strand. I learned that the hard way... ;) – André Jan 20 '11 at 10:31
2

boost::io_service::run() will return only when there's nothing to do, so no async operations are pending, e.g. async accept/connection, async read/write or async timer wait. so before calling io_service::run() you first have to start any async op.

i haven't got do you have console or GUI app? in any case multithreading looks like a overkill. you can use Asio in conjunction with your message loop. if it's win32 GUI you can call io_service::run_one() from you OnIdle() handler. in case of console application you can setup deadline_timer that regularly checks (every 200ms?) for user input and use it with io_service::run(). everything in single thread to greatly simplify the solution

Andriy Tylychko
  • 15,967
  • 6
  • 64
  • 112
2

1) What is the best-practice way of using boost::asio in a client application with regard to threads and keeping them alive?

As the documentation suggests, a pool of threads invoking io_service::run is the most scalable and easiest to implement.

2) When writing to a socket from the main thread to the IO thread, is synchronization achieved using boost::asio::post, so that the call happens later in the io_service?

You will need to use a strand to protect any handlers that can be invoked by multiple threads. See this answer as it may help you, as well as this example.

3) When data is received, how do people get the data back to the UI thread? In the past when I used completion ports, I made a special event that could post the data back to the main UI thread using a ::SendMessage. It wasn't elegant, but it worked.

How about providing a callback in the form of a boost::function when you post an asynchronous event to the io_service? Then the event's handler can invoke the callback and update the UI with the results.

Community
  • 1
  • 1
Sam Miller
  • 23,808
  • 4
  • 67
  • 87
  • thanks for this information. The issue was that my callbacks are being called from the thread that calls `io_service::run`, which is not the main UI thread. I think I will solve this by having a proxy delegate that uses SendMessage to invoke another delegate on the UI thread. As for the strands, I have used them. However, I used `io_service::post(strand_.wrap(` rather than `strand::post`, is this incorrect? – Moo-Juice Jan 20 '11 at 12:07
  • @Moo-Juice it depends on the context where they are used, both post and wrap are very similar. – Sam Miller Jan 20 '11 at 12:58
  • well, I use **post** at the socket level, e.g, when I send data the public interface posts to an internal one which starts `async_write_some`. A high-up abstraction (that queues commands to be transmitted) uses the **wrap** on it's methods as not only can it be posted from any thread, but it sets up it's own deadline timers (to prevent the queue being sent too fast). – Moo-Juice Jan 20 '11 at 13:41
  • you only have to use a strand for your callback if your handlers are not threadsafe of course. – André Jan 21 '11 at 07:59
0

When data is received, how do people get the data back to the UI thread? In the past when I used completion ports, I made a special event that could post the data back to the main UI thread using a ::SendMessage. It wasn't elegant, but it worked

::PostMessage may be more appropriate.

Unless everything runs in one thread these mechanisms must be used to safely post events to the UI thread.