Re: [asio-users] [strand] Bug: Handlers execute on the wrong strand.

[Greg B. <gre...@gm...>]

Hi All,

Thanks for your responses. I wish I had of posted here earlier rather than
the boost lists.

On 24 October 2013 16:54, Marat Abrarov <ab...@ma...> wrote:

> > It may be a change of behaviour and a problem for you, but strictly
> > speaking I don't think it is a bug. The strand concept guarantees that
> > handlers wrapped on the _same_ strand will _not_ execute concurrently. It
> > does not guarantee that handlers wrapped on _different_ strands _will_ be
> > allowed to execute concurrently.
>
> I think this has to be noted in documentation to prevent misunderstanding.


Yes I agree with this. When I realised what was happening I looked at the
documentation very closely to for any hints as to whether the behavior was
expected. The documentation doesn't fully explain the current operation:

"An boost::asio::strand guarantees that, for those handlers that are
dispatched through it, an executing handler will be allowed to complete
before the next one is started. This is guaranteed irrespective of the
number of threads that are calling
io_service::run()<http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/io_service/run.html>.
Of course, the handlers may still execute concurrently with other handlers
that were not dispatched through an boost::asio::strand, or were dispatched
through a different boost::asio::strand object."

The following snippet is true: "Of course, the handlers may still execute
concurrently with other handlers that were... ... dispatched through a
different boost::asio::strand object". What it doesn't say is that handlers
may execute sequentially with handlers dispatched through a different
boost::asio::strand object. There are no guarantees.

I understand that this is the desired behaviour (and why). From a users
point of view I think it is unnatural. If the user creates a strand object
they will naturally think that they operate independently as they should
not be concerned with the implementation of the object.

The documentation needs to state this clearly in some manner in both the
tutorial and reference sections.

Perhaps I need to put my hand up!


>
> > I would guess the reason it is done like this is because the alternative
> > does not scale well; if every strand has its own implementation then you
> > are continually creating and destroying mutexes and might also hit OS
> > constraints on the number of mutexes if the number of strands is large.
>
> Yes. This is the only reason. It was discussed (this mail list) some years
> ago.
>
> The best solution I see is to add additional API to create exclusive
> strands.
> Something like optional parameter at constructor of strand:
>
> 
> asio::io_service::strand(bool exclusive = false) {...}
>

This would be nice. However to make things even more explicit perhaps a
different type (

asio::io_service::strand_exclusive) may be a better option.

Regards,

-- 
Greg