Modify

Ticket #9008 (closed Bugs: fixed)

Opened 8 months ago

Last modified 8 months ago

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

Reported by: Marcello <marcello.pietrobon@…> Owned by: igaztanaga
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?

Attachments

Change History

comment:1 Changed 8 months ago by Marcello Pietrobon <marcello.pietrobon@…>

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 Changed 8 months ago by igaztanaga

  • Owner set to igaztanaga
  • Component changed from None to interprocess

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 Changed 8 months ago by igaztanaga

  • Status changed from new to closed
  • Resolution set to fixed

(In [85401]) Fixes #9008

comment:4 Changed 8 months ago by marcello.pietrobon@…

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.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.