From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-10-09 04:55:52
"Peter Dimov" <pdimov_at_[hidden]> writes:
> Anthony Williams wrote:
>> "Cory Nelson" <phrosty_at_[hidden]> writes:
>>> 2) It doesn't spin at all - giving an app a chance to stay away from
>>> WaitForSingleObject on multithreaded systems will be a good boost to
>>> scalability under typical use. Win32 critical sections have a
>>> default spin count of 4000 on multithreaded systems. With
>>> multi-core getting more and more common I think this is an important
>>> aspect to consider.
>> Yes, it's worth considering. I would be intrigued to see what
>> difference it made. I have a dual-core system and a single-core
>> system, so I could see how it performed on both with/without
>> spinning. Any ideas for how to construct a benchmark?
> I would advise against spinning. Spinning is a bit of a gamble; it may or
> may not be a win depending on several factors (average critical section
> length, spin count, whether other threads in ready state can make better use
> of the CPU time, context switch performance) and the optimal spin count is
> very application-dependent.
> It isn't a problem if the user gambles with his own money, so to speak, i.e.
> spins manually with try_lock. However it can be a problem if the
> implementation gambles with the user's money and loses, since there is no
> way to make it not spin. IOW, you can easily turn a non-spinning mutex into
> a spinning mutex, but not vice versa.
How about a try_lock(spin_count) call? or even a lock(spin_count)? Would that
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk