Use InitializeCriticalSectionAndSpinCount instead of IntializeCriticalSection.
Using spin counts for critical sections of short duration enables the calling
thread to avoid the wait operation in most situations which can dramatically
improve the overall performance on multiprocessor systems.
On Linux this change has no effect because the new winpr critical section
implementation does not use the SpinCount field under Linux because the NPTL
synchronization primitives are implemented using the extremely performant
futex system calls which have this magic already built in.
However, on Mac OS X this change improved the overall performance of the
multithreaded RemoteFX decoder by 25 percent.
I've used a SpinCount of 4000 which avoided 99 percent of the wait calls.
This value is also used by Microsoft's heap manager for its per-heap
critical sections.
Note: This change requires pull request #1397 to be merged.
- Complete implementation including recursion support
- Added an intensive ctest (TestSynchCritical)
- Struct members are used exactly as Windows does it internally:
LockCount starts at -1, RecursionCount at 0
- Same performance optimizations as internally on Windows:
- Fast lock acquisition path using CAS -> SpinCount -> wait
- SpinCount automatically disabled on uniprocessor systems
- On Linux SpinCount is disabled because it provided no advantage over NPTL/futex in all tests
Support for CRITICAL_SECTION's DebugInfo is not yet included (but trivial to add).
- Improved/completed(almost) winpr's critical section implementation
- Replaced WaitForSingleObject locking with critical sections
Note:
WaitForSingleObject should _never_ be used for granular low-contention
locks as it _always_ enters the kernel.
Just replacing WaitForSingleObject locking in Bufferpool with
EnterCriticalSection boosts the multithreaded rfx decoder
performance by almost 400% on win32.
The WaitForSingleObject call on TilePool's event is called with a zero time-out
interval and the event is a manual reset event ... thus no locking or waiting
is involved anyways and Queue_Dequeue may very well return NULL independently
of calling WaitForSingleObject which is already correctly handled.
