Roland Schwarz wrote:
stas garifulin wrote:
I'm using vc71 with multi-threaded runtime. Sometimes then boost::spirit code is accessed from different threads simultaneously i have access violation at boost/spirit/core/non_terminal/impl/grammar.ipp (255):
# ifdef BOOST_SPIRIT_THREADSAFE static boost::thread_specific_ptr<ptr_t> tld_helper; // <-- Here if (!tld_helper.get()) tld_helper.reset(new ptr_t); ptr_t &helper = *tld_helper; # else
I am afraid the usage of thread_specific_ptr as a local static object is "implementation dependant". The constructors might be called when "first time control passes through its declaration". This would be bad. As far as I know thread_specific_ptr is expected to be constructed before main. Also what does "first time" mean when MT is involved? The standard does not know about MT. Will it be called twice?
I think the poiner should be moved to file scope.
Some additional information: Altough the thread_specific_ptr ctor tries to guard itself against concurrent access of its underlying tss_data struct, it is not prepared to be multiply called. Declaring a local static object on the other hand protects multiple calls to the ctor by setting a local flag and scheduling a call for its dtor to atexit. It is exactly this setting of the flag that poses a race condition, since it is not protected by a critical section. Altough it might work to internally protect the ctor against multiple invocation, this would not solve the race condition. The side effect would be to schedule two calls to atexit for the destructor, which is equally bad. The broader question is: Can local static objects ever be made thread safe? Or should they be avoided at all in MT aware code? Roland
Roland
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost