Re: [boost] Problems with yield_k workaround. Still too slow.

Subject: Re: [boost] Problems with yield_k workaround. Still too slow.
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2013-08-21 06:14:03

El 21/08/2013 10:41, Peter Dimov escribió:
> I do not object to such a change (32 -> 1024 and perhaps 16 -> 64 or
> higher for the 'pause' case as well); however, it would be prudent to
> first test it against other usage scenarios. I can provide two test
> cases that would likely be affected, sp_atomic_mt_test.cpp and
> sp_atomic_mt2_test.cpp, and I'm sure that there are other Interprocess
> usage examples that can be checked.
>
> http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/test/sp_atomic_mt_test.cpp
>
> http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/test/sp_atomic_mt2_test.cpp

As I wrote in the "[Boost.Interprocess] conditions variables get 10 
times faster when opening a multiprocess browser" thread:

"It's definitely hard to tell if 1000 will be OK for everyone, as it 
might depend on the CPU speed or waiter count". It might also depend on 
the CPU count (on uniprocessor we should always yield)

spinlock implementations found on the net are quite varied:

-> some only yield once and sleep after that because they say it's 
better on high contention cases
-> some just spin (optimized for very short waits).
-> some measure wait times to know how much to spin

http://www.1024cores.net/home/lock-free-algorithms/tricks/spinning

http://src.chromium.org/svn/trunk/src/third_party/tcmalloc/chromium/src/base/spinlock.cc

I'm afraid there is no a unique solution. In Marcello's example 
(condition variable) I think he needs to yield current timeslice to the 
sibling thread as it needs a fast roundtrip between the waiter and the 
notifier.

Best,

Ion