From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ion Gaztañaga Sent: Thursday, October 23, 2008 12:58 PM
Because Boost.Thread mutex might be a bit heavier (at least in windows) than Boost.Pool's CriticalSection calls. I see Anthony is using atomic operations in Boost.Thread to minimize the issue of the internal event so please profile the performance before changing this.
I will benchmark the pool before and after to get a concrete idea of what the impact may be. Even if there is a slight additional penalty for using boost::mutex I think I am inclined to use it as the default anyway. Doing so removes a chunk of platform-dependent code from Boost.Pool while at the same time making it more transparent about how it might interact with other thread-safe/aware components in Boost. If there are special circumstances which require the absolute lowest synchronization overhead possible and a "better" mutex can be written, singleton_pool is still parameterized on the mutex type and the user can plug in anything that covers the Lockable concept. As an side, I'm curious why boost::mutex is implemented with basic_timed_mutex on Windows. It seems like there could be a dedicated mutex implementation using CriticalSection which, as far as I know, covers the Lockable concept. -Chris