On 31 Oct 2013 at 12:12, Gavin Lambert wrote:
ASIO is, once you compile it with optimisation, really a thin wrapper doing a lot of mallocs and frees around Win IO completion ports. Any latency spikes are surely due to either IOCP or the memory allocator causing a critical section to exceed its spin count, and therefore go to kernel sleep?
No, the latency was very definitely coming from *some* instance of either boost::asio::detail::mutex or boost::asio::detail::static_mutex. I didn't trace it down any further than that.
From what I can tell ASIO uses Win32 critical sections which come with spin counts. If you keep every operation under the count, all is good, else you get spikes as it drops to kernel wait.
(As far as the memory allocator goes, I'm actually using nedmalloc -- which I know isn't lock-free but it's pretty decent at avoiding lock contention. And I had that instrumented too and there were no memory allocation locks around the time when the latency occurred.)
I might know something about nedmalloc :). Mmm, I was just about to suggest that nedmalloc might be doing a free space consolidation run and that might be the cause of the spike, but if it isn't then okay.
My application was using an io_service with 6-8 threads, and a large number of serial_ports each with their own io_strand and deadline_timer. The deadline_timer is cancelled and restarted most of the time rather than being allowed to expire -- but this shouldn't be unusual behaviour for a timeout.
It just goes to show how complex and unpredictable modern C++ has become :( At the bleeding edge we're actually all complex systems engineers now, not software or computer science engineers. I wish how we as an industry interview job hire candidates reflected that (or I wouldn't be having the problems I have had!). Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/