Static variables and threads

[Jeremie]

Hi,

class A
{
<..>
};

const A& GetA()
{
static A a;
return a;
}


is the function GetA() safe in a multi-threaded application (one and
only one A is created) ? I suppose "threads" are not part of c++, but
what about the "common implementation" ?

Thanks,

Jeremie

 

[Victor Bazarov]

class A
{
<..>
};

const A& GetA()
{
static A a;
return a;
}


is the function GetA() safe in a multi-threaded application (one and
only one A is created) ? I suppose "threads" are not part of c++, but
what about the "common implementation" ?

Please ask about "common implementation" in comp.programming.threads.
C++ does not define anything related to threads and therefore there are
no guarantees one way or the other. That's probably why C++ compiler
implementers do not concern themselves with threading issues. At least
I wouldn't if I were to implement a C++ compiler.

As far as I understand threading, access to a singleton has to be made
safe (using available threading means, like critical sections, mutexes,
etc.) otherwise you run in all kinds of problems when two threads try
to simultaneously change the object or two others try to use the object's
value that can be half-way updated by the other two threads... The fact
that 'A' is declared const doesn't matter. You can still have "mutable"
data in A, or static members that are not affected by constness of any
object of that class.

Of course, if you can make sure that no clients of 'GetA' try to cast
away the constness of it and change it _and_ that no A object has any
mutable data that can change _and_ class A doesn't have any static data
members that also can change at any point, then yes, it's safe, I guess.
But can you really make sure that all those conditions are met?

Victor

 

[JKop]

Jeremie posted:

Hi,

class A
{
<..>
};

const A& GetA()
{
static A a;
return a;
}


is the function GetA() safe in a multi-threaded application (one and
only one A is created) ? I suppose "threads" are not part of c++, but
what about the "common implementation" ?

Thanks,

Jeremie

The very simple answer is look at your code and figure it
out.

If GetA() is called for the first time from Thread1, then
grand. If GetA() is called for the first time from Thread2,
and then Thread2 ends, will Thread1 be able to still work
with it? The answer is:


OFF-TOPIC


-JKop

 

[Gianni Mariani]

Hi,

class A
{
<..>
};

const A& GetA()
{
static A a;
return a;
}


is the function GetA() safe in a multi-threaded application (one and
only one A is created) ?

All compilers I have used get this wrong and do not do thread safe
initialization of static function variables.

The standard does guarentee that the variable 'a' gets initialized
exactly once when GetA is called. Hence, wether the C++ standard
"knows" about threads or not, an implementation must guarentee this.

There is a gcc bug that covers this now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684

It has been reported a few times.

I suppose "threads" are not part of c++, but

 

[SaltPeter]

Hi,

class A
{
<..>
};

const A& GetA()
{
static A a;
return a;
}


is the function GetA() safe in a multi-threaded application (one and
only one A is created) ? I suppose "threads" are not part of c++, but
what about the "common implementation" ?

Your off-topic. Its precisely because A is unique that thread safety is
compromised. As already mentioned, proprietary implementations like threads,
mutexes, events, semaphores and critical sections are designed to isolate
and lock the instance of A to fix that issue although race conditions will
persist. But such a scenario is delibitating since only MS operating systems
need apply.

Which is the main reason why the folks in this newsgroup prefer not to deal
with it(thankfully so). A window implies not a rectangle or frame, but
rather a proprietary target with a proprietary message loop, which are
required to support most kinds of these proprietary, void passing threads
and processes. So multi-threading is most likely to remain off-topic.

Its not imposed by the newsgroup, rather, it's MS's decision purely.

 

[Jeremie]

JKop a exposé le 24/07/2004 :

Jeremie posted:


The very simple answer is look at your code and figure it
out.

If GetA() is called for the first time from Thread1, then
grand. If GetA() is called for the first time from Thread2,
and then Thread2 ends, will Thread1 be able to still work
with it? The answer is:

but if GetA() is called for the first time from thread1 AND thread2 ?
is one A or two A created ? this was my question

 

[Jeremie]

Gianni Mariani a couché sur son écran :

All compilers I have used get this wrong and do not do thread safe
initialization of static function variables.

The standard does guarentee that the variable 'a' gets initialized exactly
once when GetA is called. Hence, wether the C++ standard "knows" about
threads or not, an implementation must guarentee this.

There is a gcc bug that covers this now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684

It has been reported a few times.

Thanks

Jeremie

 

[JKop]

Jeremie posted:

but if GetA() is called for the first time from thread1 AND thread2 ?
is one A or two A created ? this was my question

Platform-specific.


WinXP : Don't know
Linux : Don't know
Unix : Don't know
MSDOS version 3 : Don't know


Most likely once, and it's available until the entire process is terminated,
which occurs when there's no threads left.



-JKop

 

[DaKoadMunky]

It is possible you will find this of interest...

http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx

 

[Alexander Terekhov]

SaltPeter wrote: ...

Clap clap.

regards,
alexander.

 

[Dave Townsend]

Jeremie,

It looks to me that this is NOT a thread safe construct.

If you have two threads, thread1 and thread2, thread1 calls
GetA() and is preempted during the construction of the static
Object A, then thread2 calls GetA(), thread2 now accesses a partially
constructed A and the results are undefined.

You need to guarantee that A will be completely constructed before
a second thread accesses it. If you construct A in the main thread, before
the worker threads start, this will work, or use some kind of thread sync
objects to prevent subsequent threads from accessing A during its
construction.

Presumably the class A has its own synchronization mechanisms
internally ( unless of course its a read-only type object).