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