Can Q_GLOBAL_STATIC replace KStaticDelete ?

Matthias Kretz kretz at
Thu Jan 18 21:00:53 GMT 2007

On Thursday 18 January 2007 20:34, Thiago Macieira wrote:
> Matthias Kretz wrote:
> >On Thursday 18 January 2007 12:13, Thiago Macieira wrote:
> >> We cannot also rely on the C++ compiler having guards against
> >> reentrancy in static objects.
> >
> >Meaning we may not rely on
> >static QGlobalStatic<TYPE > this_##NAME;
> >to be atomic?
> QGlobalStatic doesn't do anything. It's just a struct with a destructor.
> It's the object creation and assignment that has to be thread-safe. That's
> why we need QAtomic, because the language itself provides no guarantees.

The problem is that if thread 1 inits this_##NAME and then executes the code 
in the macro (creating a new object and returning it) while thread 2 does the 
same, the internal flag that the local static has been initialized might 
still be unset so that thread 2 creates a second QGlobalStatic object which 
tells the macro that the object has not been created yet.

Testcase attached. The testcase has been compiled with -fno-threadsafe-statics 
to make g++ not add the atomic behaviour of local statics.

After many successful static object creations I get this:
ASSERT: "t1.a == t2.a" in file static.cpp, line 34

Matthias Kretz (Germany)                            <><
MatthiasKretz at, kretz at,
Matthias.Kretz at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: static.cpp
Type: text/x-c++src
Size: 517 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list