Anthony Williams wrote:
> Thomas Richter <thor@[EMAIL PROTECTED]
> writes:
>
>> Brian Cole wrote:
>>> I know that static initialization is not considered threadsafe from
>>> previous posts on this list. However, if a function static is POD
>>> being initialized by a function call then the value should always be
>>> initialized correctly, even if a inconsequential race condition
>>> occurs. This assumes that POD assignments are atomic, what platforms
>>> is this not true on?
>> All I know of. For example,
>>
>> struct foo {
>> int a,b;
>> };
>>
>> static struct foo f = {1,2};
>>
>> is a POD initialization, and if two threads run into this line of
>> code, it may happen that thread A initializes f.b while thread B is
>> already using f.b for something else, so no, this is definitely not
>> safe.
>
> Wrong. Initialization of a POD struct with an aggregate initializer
> consisting only of constant expressions is static initialization and
> must happen before the execution of the program begins.
Is this guaranteed? I don't think it is, and I doubt you can depend on
it. Specifically, f is non-const here, so the compiler should have IMHO
the freedom of placing the initializer into the code/text section, and
copy the data on demand during execution so code can modify it. This is
what g++ does, and it would definitely be not safe wouldn't gcc wrap
this test into a mutex. AFAIK, the only requirement that does exist is
that f must be initialized before the first usage, and that might be
after loading time.
Things *might* be better with const, they definitely are for g++, but
once again, I cannot find this requirement in the C standard.
So long,
Thomas
|
