$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2007-02-05 16:02:36
Fabien Niñoles wrote:
>> Quote from http://msdn2.microsoft.com/en-us/library/s1sb61xd.aspx:
>> "Assigning to a static local variable is not thread safe and is not
>> recommended as a programming practice."
>>
>> Although this isn't very concise wording (IIRC, the standard says
>> that it should work for literals assigned to PODs) it seems clear
>> that it won't work for non-PODs...
>>
>
> The example below the warning clearly show up what they mean, and it's
> really a concurrency situation where two threads access the same
> object.
I don't see how the quoted example has any bearing on MT issues. It is a
single threaded program.
> So, yes, this is a bad practice, and it is clearly not thread-safe,
> even for POD:
I should have been clearer. The standard sais that *initializing* a POD
is not a problem because that is done before any threads have a chance
to race against each other (typically when the binary is loaded into
memory). In the example, the second assignment to the POD is indeed a
problem because it must happen at runtime. What I meant with my original
statement is the following:
class NonPod
{
public:
NonPod() { /* ... */ }
};
class Whatever
{
public:
static int & GetPodInstance()
{
static int podInstance = 42;
return podInstance;
}
static NonPod & GetNonPodInstance()
{
static NonPod nonPodInstance;
return nonPodInstance;
}
};
When multiple threads are present, there's no race condition when more
than one of them call GetPodInstance(). Clearly there is one when they
call GetNonPodInstance() because NonPod::NonPod() will non run before
the first call...
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.