Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#9008 closed Bugs (fixed)

[Boost.Interprocess] conditions variables fast enough only when opening a multiprocess browser

Reported by: Marcello <marcello.pietrobon@…> 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 Marcello Pietrobon <marcello.pietrobon@…>, 9 years ago

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?

comment:2 by Ion Gaztañaga, 9 years ago

Component: Noneinterprocess
Owner: set to Ion Gaztañaga

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:3 by Ion Gaztañaga, 9 years ago

Resolution: fixed
Status: newclosed

(In [85401]) Fixes #9008

comment:4 by marcello.pietrobon@…, 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.

Note: See TracTickets for help on using tickets.