Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-01-17 12:25:37


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
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk