Boost logo

Boost Users :

Subject: Re: [Boost-users] [Asio] Socket Read/Write Thread-Safety
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-31 06:39:31


On Mon, Jan 31, 2011 at 7:30 PM, Timothy Liang <timothy003_at_[hidden]> wrote:
>> <<In the case of composed asynchronous operations, such as async_read() or
>> async_read_until(), if a completion handler goes through a strand, then
>> all intermediate handlers should also go through the same strand. This is
>> needed to ensure thread safe access for any objects that are shared
>> between the caller and the composed operation (in the case of async_read()
>> it's the socket, which the caller can close() to cancel the operation).
>> This is done by having hook functions for all intermediate handlers which
>> forward the calls to the customisable hook associated with the final
>> handler>>
>>
>> http://www.boost.org/doc/libs/1_45_0/doc/html/boost_asio/overview/core/strands.html
>
> Ah!  It also says, "The io_service::strand::wrap() function creates a new
> completion handler that defines asio_handler_invoke so that the function
> object is executed through the strand."  And the composed operations have a
> hook on their intermediate handlers that call asio_handler_invoke with the
> completion handler's context.  So I simply need to pass the wrapped handler
> object directly to the composed operations as the completion handler.  Cool.
>
> Now I'm beginning to wonder if this will work with my design.  I want my
> program to run handlers as concurrently as possible.  I'm currently using a
> single io_service and setting up a thread pool like the HTTP Server 3
> example.  Since the io_service doesn't know if a handler would be blocked by
> a strand, it could needlessly assign an about-to-be-blocked handler to a
> free thread.  How do I fix that?
>

It doesn't do that. It's smart enough to see that it's in a given
strand which may be blocked so it moves on to the next available
scheduled handler. I do it all the time and I haven't seen it be the
bottleneck for anything I've developed with Boost.Asio even in the
early days and leading up to especially now.

Give it a shot and then measure to identify which part of the solution
is causing you problems.

HTH

-- 
Dean Michael Berris
about.me/deanberris

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net