I was just looking at the win32 implementations of the various
Boost.Thread mutex classes (specifically basic_recursive_mutex). I was
surprised to see that they use WaitForSingleObject internally, rather
than a CRITICAL_SECTION.
I've found mentions that it originally used a CRITICAL_SECTION, but no explanation of why it was changed.
It
seems to me, personally, that the hybrid locking functionality of the
CRITICAL_SECTION implementation would be more desirable than the
WaitForSingleObject implementation in most use cases.
Is there a reason for this choice? At first glance, it looks like it
was just done to re-use code from the timed_mutex, which can't (easily)
be implemented with CRITICAL_SECTION.
Regards,
Collin