Re: [boost] [pool] Conversion to Boost.Thread for singleton_pool

Subject: Re: [boost] [pool] Conversion to Boost.Thread for singleton_pool
From: Chris Newbold (Chris.Newbold_at_[hidden])
Date: 2008-10-24 09:01:44

> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> 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