[pool] Conversion to Boost.Thread for singleton_pool
Boost.Pool contains a private mutex implementation used as the default mutex type for singleton_pool (which provides a thread-safe API). Now that Boost.Thread is well-established and in line with TR1, I'd like to jettison the private mutex implementation inside Boost.Pool and switch the default mutex type to be boost::mutex. The obvious consequence of this change is that singleton_pool becomes dependent on Boost.Thread. The dependency would exist only for singleton_pool and its clients and would not affect the other Boost.Pool interfaces. Anyone have any objections or reasons why this wouldn't be a good idea? -Chris
Chris Newbold wrote:
Boost.Pool contains a private mutex implementation used as the default mutex type for singleton_pool (which provides a thread-safe API). Now that Boost.Thread is well-established and in line with TR1, I'd like to jettison the private mutex implementation inside Boost.Pool and switch the default mutex type to be boost::mutex.
The obvious consequence of this change is that singleton_pool becomes dependent on Boost.Thread. The dependency would exist only for singleton_pool and its clients and would not affect the other Boost.Pool interfaces.
Anyone have any objections or reasons why this wouldn't be a good idea?
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. Also, I don't like much the idea of another linking dependency, but that's a personal taste issue.
-Chris
Regards, Ion
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 24 October 2008 09:01 am, Chris Newbold wrote:
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.
TryEnterCriticalSection doesn't exist on windows 9x, and Lockable includes a try_lock() method. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJAcuv5vihyNWuA4URApe6AJ4w4+FOniEYtq3Z4R6PAEzukD5dWACgg8Oz ym5GzSlEh6g/zDbpF09W4Ak= =D5M3 -----END PGP SIGNATURE-----
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Frank Mori Hess Sent: Friday, October 24, 2008 9:21 AM
On Friday 24 October 2008 09:01 am, Chris Newbold wrote:
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.
TryEnterCriticalSection doesn't exist on windows 9x, and Lockable includes a try_lock() method.
We still have to support Windows 9x, huh? Oh well... :) -Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 24 October 2008 09:30 am, Chris Newbold wrote:
TryEnterCriticalSection doesn't exist on windows 9x, and Lockable includes a try_lock() method.
We still have to support Windows 9x, huh? Oh well... :)
I work much with windows so I don't care personally, but maybe compiler support would be the larger issue. It is only with microsoft visual c++ 2008 that they stopped including windows 9x as a targeted platform by default. So with visual c++ 2005 TryEnterCriticalSection doesn't exist by default. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJAdSL5vihyNWuA4URAuk6AKC6ZNHtTb320HB8pzR67bEn1YR8ZgCgzQdX Zn+6fo4m/xrCoQZz/qaBD8U= =+o0g -----END PGP SIGNATURE-----
participants (3)
-
Chris Newbold -
Frank Mori Hess -
Ion Gaztañaga