[Boost-bugs] [ boost-Bugs-1370716 ] BOOST_SP_USE_QUICK_ALLOCATOR and BOOST_AUTO_UNIT_TEST
Bugs item #1370716, was opened at 2005-12-01 11:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1370716&group_id=7586 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Martynov (alexey_martynov) Assigned to: Nobody/Anonymous (nobody) Summary: BOOST_SP_USE_QUICK_ALLOCATOR and BOOST_AUTO_UNIT_TEST Initial Comment: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1370716&group_id=7586 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs
Initial Comment: 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.
This is frequently met issue with global variables. Peter will you be able to handle this? Gennadiy
Gennadiy Rozental wrote:
Initial Comment: 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.
This is frequently met issue with global variables. Peter will you be able to handle this?
I'm not sure how. Turning a mutex into a singleton defeats the whole point of using a mutex, because it introduces an initialization race. But I'll try to think of something that improves the current situation.
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.
This is frequently met issue with global variables. Peter will you be able to handle this?
I'm not sure how. Turning a mutex into a singleton defeats the whole point of using a mutex, because it introduces an initialization race. But I'll try to think of something that improves the current situation.
I am not sure there is a way around this. It should be created on request. Otherwise no global/static variables could use smart_ptr, isn't it? Gennadiy
Gennadiy Rozental wrote:
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.
This is frequently met issue with global variables. Peter will you be able to handle this?
I'm not sure how. Turning a mutex into a singleton defeats the whole point of using a mutex, because it introduces an initialization race. But I'll try to think of something that improves the current situation.
I am not sure there is a way around this. It should be created on request. Otherwise no global/static variables could use smart_ptr, isn't it?
Only with BOOST_SP_USE_QUICK_ALLOCATOR defined. I'll try to come up with something.
participants (1)
-
Gennadiy Rozental -
Peter Dimov -
SourceForge.net