Re: [boost] [asio] Bug: Handlers execute on the wrong strand (Gavin Lambert).

Subject: Re: [boost] [asio] Bug: Handlers execute on the wrong strand (Gavin Lambert).
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-10-25 02:39:57

On 24/10/2013 22:27, Quoth Marat Abrarov:
>> I actually ended up abandoning Asio and rolling my own threadqueue (I
>> didn't want any of the socket-related stuff so this wasn't as big a job
>> as it sounds).  Mine isn't fully-baked yet (and it's Windows-only for
>> the moment) and I'm not sure I'd want to show it off either, but on the
>> upside most of the guts are entirely lock-free (though not wait-free,
>> since it's based on Boost.LockFree's queue).
>
> Asio at Windows uses IOCP (default settings, using asio::io_service for task
> scheduling) and that is the (theoretical) reason of better thread scheduling
> for the Asio-based thread pool. Sometimes it's really visible.

It's also full of mutexes though, which is why it didn't work out for 
me.  (Note that I was using Boost 1.53 when testing Asio; maybe this has 
changed in future versions, although I heard that 1.54 picked up a bug 
in the IOCP reactor.)

I'm not sure exactly which lock triggered the slow path (my logging was 
only sufficient to show that it was one of the ones inside Asio, but not 
which one).  But as the prior email said, given reuse of strand 
implementations between supposedly independent strands, that seems like 
a likely candidate.  (Though it didn't take long for the latency spikes 
to manifest -- typically they'd start after a couple of minutes and then 
recur roughly every 10-30 seconds.)

My implementation also uses IOCP for the io_service equivalent but 
without the dispatch queue mutexes that Asio uses.  The Boost.LockFree 
queue is used mostly for the io_strand and object_handle equivalents 
(and even then it's only used by the latter to support multiple 
concurrent waiters, which I didn't end up needing).  (The strand, of 
course, is still blocking in the execution path but not in the posting 
path.)

I haven't done a head-to-head benchmark on each (and it wouldn't 
surprise me if Asio were faster than mine for many loads -- and it's 
definitely more flexible than I made mine) but so far my one is doing at 
least as well as Asio on production loads but without the latency spikes 
from the locks.  Still very early days yet though.