"Peter Dimov" <pdimov@mmltd.net> writes:
Anthony Williams wrote:
"Cory Nelson" <phrosty@gmail.com> 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 be superfluous? Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk