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.c...
http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/test/sp_atomic_mt2_test....
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... 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