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