BOOST_SP_USE_QUICK_ALLOCATOR and BOOST_AUTO_UNIT_TEST

[alexey_martynov]

When using BOOST+AUTO_UNIT_TEST and
BOOST_SP_USE_QUICK_ALLOCATOR and BOOST_HAS_THREADS
macros under Windows (MSVC71) Access Violation occurs
in "lightweight_mutex::scoped_lock::scoped_lock".
This behavior produced by error in
"boost::detail::allocator_impl" or in Test Framework.
Mutex for locking created by static member. Automatic
unittests created by using global variables. So we have
using uninitialized CRITICAL_SECTION because order of
global variables initialization is undefined.

I tried to convert
"boost::detail::allocator_impl::mutex" from static
variable to Meyer's singleton (with static member
function which contains local static variable "mutex").
This solves my problem but I can't suggest any patch
because I can't test it with many compilers.

[Peter Dimov]

Logged In: YES 
user_id=305912

Fixed in CVS.

[nobody]

Logged In: NO 

I see to changes and have following question: what you think
about potential "allocator_impl::mutex()" method inlining?
If it will be inlined (because defined in body of struct) we
will have thread synchrnization errors.

[Peter Dimov]

Logged In: YES 
user_id=305912

Inlining doesn't affect behavior (unless the compiler is
buggy); all inlined copies (should) share a single static
variable and initialization flag. We could move the
definition outside the class, but some compilers will inline
it anyway, because the definition will still be visible to them.