#9008 closed Bugs (fixed)
[Boost.Interprocess] conditions variables fast enough only when opening a multiprocess browser
Reported by: | Owned by: | Ion Gaztañaga | |
---|---|---|---|
Milestone: | To Be Determined | Component: | interprocess |
Version: | Boost 1.54.0 | Severity: | Problem |
Keywords: | Cc: |
Description
Hi Boost team, getting a weird behaviour on XP SP3 Boost 1.54.0 (with stlport)
Interprocess library example with:
comp_doc_anonymous_conditionA.cpp comp_doc_anonymous_conditionB.cpp
When running some speed tests the time between two messages (round-trip) is of 15 ms (quite slow for what I need), but if I open a multiprocess browser (Chrome or Firefox 4.0, not with IE8) the speed instantly increases to 1.5 ms which starts to be acceptable to me. If If I minimize the browser the program slows down again.
Any idea why is this happening? Is there any fix or workaround for this?
Change History (4)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Component: | None → interprocess |
---|---|
Owner: | set to |
I've replaced all thread_yield with a new yield(unsigned) call that is based on Boost.SmartPointer's "yield_k" functions. This function increasingly tries to use heavier wait functions. First mm_pause, then SwitchToThread/Sleep(0) and finally Sleep(1).
Iteration thresholds are taken from Boost.SmartPointer code, and those might not be optimal for all CPU types, number of concurrent threads, etc. I'll fix the bug with the commit, but reopen it if this doesn't solve the issue.
comment:4 by , 9 years ago
I've run some tests on it and it has improved the performance, but not completely.
Clearly this problem is not limited to your interprocess library so I thought to open a different thread discussion for it i the forum: http://boost.2283326.n4.nabble.com/Problems-with-yield-k-workaround-Still-too-slow-td4650929.html
I've done some profiling plus some tests and so it's clear to me that the test program is still slowed down around the ::sleep(1) instruction, and so the value 32 in yield.hpp needs to be replaced with a much higher value.
I've applied the workaround suggested by Gav Wood in http://boost.2283326.n4.nabble.com/Boost-Interprocess-conditions-variables-get-10-times-faster-when-opening-a-multiprocess-browser-td4650763.html#a4650797 and that seem to be able to completely fix the problem.
Even though this problem seems to be entirely due to the inner working of Windows OS, is it possible to optionally implement Gav's workaround in the library, despite all the sensible reservation expressed in the above post, considering that that gives an increase in performance up to almost 1000 times?