-----Ursprüngliche Nachricht----- Von: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] Im Auftrag von Anthony Williams Gesendet: Montag, 12. Juli 2010 19:08 An: boost-users@lists.boost.org Betreff: Re: [Boost-users] Memory management of boost::mutex

Markus Henschel writes:

...

we have a custom memory manager that overrides global new/delete. It is currently not thread safe. Because we require thread safety now I wanted to ad a mutex and some locks around the critical parts. Unfortunately boost::mutex allocates memory itself.

boost::mutex does not directly allocate any memory itself, so this should not be a problem. Which version of boost are you using, on which platform?

Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Currently we use 1.34.1 but will soon upgrade to 1.43.0. At least in 1.34.1 when BOOST_HAS_WINTHREADS is defined a mutex allocates memory for a win32 CRITICAL_SECTION using new operator. It seems like the implementation in 1.43.0 has changed completely. Would be great if there was no more dynamic memory allocation. On the other hand I can never be sure if boost mutex will change the implementation again in future versions. Mmmmmm...

...

Currently we use 1.34.1 but will soon upgrade to 1.43.0. At least in 1.34.1 when BOOST_HAS_WINTHREADS is defined a mutex allocates memory > for a win32 CRITICAL_SECTION using new operator. It seems like the implementation in 1.43.0 has changed completely. Would be great if there was no more dynamic memory allocation. On the other hand I can never be sure if boost mutex will change the implementation again in future versions. Mmmmmm...

Nor can you be sure that the win32 CRITICAL_SECTION implementation won't change

I don't see the point. The windows API is purely C so CRITICAL_SECTION will never invoke any kind of new operator in my code no matter if the implementation changes. Relying on boost::mutex not doing any memory allocations can only be safe if this guarantee is given by the developers for future versions or if boost::mutex would provide support for user defined allocators.