- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
According to my debugger, atomic
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmm, I appear to be having other problems I haven't had before, so perhaps my original post is irrelevent. I just created a simple atomicand it didn't initialize to zero either, instead containing a bogus uninitialized value. Something weird is going on.
template// Primary template
struct atomic_base {
I my_value;
};
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
template// Primary template
struct atomic_base {
I my_value;
};
This seems contradictory to what James Reinders' TBB books says:
"You can rely on zero initialization to initialize an atomic
Anyways, I tried doing something like:
[cpp]tbb::atomic( foo );[/cpp]
which still gave me garbage.
What I finally found that works is:
[cpp]tbb::atomicfoo( boost::initialized_value );[/cpp]
using the boost utility library (http://www.boost.org/doc/libs/1_36_0/libs/utility/value_init.htm).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This seems contradictory to what James Reinders' TBB books says:
"You can rely on zero initialization to initialize an atomic
Without more context, it's hard to say what the quotation really says (at the moment, I do not have the book next to me). I guess the context might be explanation of why there is no constructors for tbb::atomic. What I think is really meant there is that if you have memory that contains zeroes, and interpret it as tbb:atomic, it will work. How you get zero-initialized memory is another question; it could be a file-scope variable for example. Sorry if the book confused you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This seems contradictory to what James Reinders' TBB books says:
"You can rely on zero initialization to initialize an atomic
Anyways, I tried doing something like:
[cpp]tbb::atomic( foo );[/cpp]
which still gave me garbage.
What I finally found that works is:
[cpp]tbb::atomicfoo( boost::initialized_value );[/cpp]
using the boost utility library (http://www.boost.org/doc/libs/1_36_0/libs/utility/value_init.htm).
Why it seems contradictory? Have you tried zero-initialization?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Why it seems contradictory? Have you tried zero-initialization?
Well, I'm using the atomic as a member variable of a class, so I need to initialize it in the initializer list. I tried initializing it like this:
[cpp]class Foo { public: Foo(); private: tbb::atomicm_atomic; } Foo::Foo() : m_atomic() { }[/cpp]
and the value was still uninitialized.
Replacing m_atomic() with m_atomic( tbb::atomic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Replacing m_atomic() with m_atomic( tbb::atomic
Please note, that copy-construction for atomics is not atomic (I'm talking about m_atomic( tbb::atomic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Based on this evidence, my best guess is a compiler deficiency.
Yeah, it seems that it's a bug in MSVC (I've checked MSVC8 and 9). MSVC correctly zero-initializes POD types, but fails to do so for non-POD types w/o user-defined constructor (i.e. tbb::atomic<>).
g++ 3.4.6 correctly zero-initializes types like tbb::atomic<>.
Yikes!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But this does not mean that class-scope atomic will get zero-initialized
I think you are confusing term 'zero-initialized'. 'Zero-initialized' is a defined term in ISO C++, which refers to some forms of initialization like initialization of objects with static storage duration AND ALSO to initialization of primitive object members provided that object is declared with empty parenthesis, i.e. "()".
This means that tbb::atomic<>'s value MUST BE '0', if atomic is declared like:
tbb::atomic
Thats how I interpret Reinders' statement "You can rely on zero initialization to initialize an atomic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's a bug in the copy assignment operator for atomic pointers (argument passed by value instead of by reference).
And what is the meaning of "such constructors could lead to accidental introduction of compiler temporaries" in the Reference Manual (I don't see how not defining a constructorwould preventthat). It might be nice to have a statement about zero-initialisation as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's a bug in the copy assignment operator for atomic pointers (argument passed by value instead of by reference).
Why is it a bug?
It's better to pass simple objects 'by value' instead of 'by reference', because 'by reference' physically means 'by pointer', and 'by pointer' creates additional level of indirection (i.e. there will be additional dereference operation, unless function is inlined).
And what is the meaning of "such constructors could lead to accidental introduction of compiler temporaries" in the Reference Manual (I don't see how not defining a constructorwould preventthat). It might be nice to have a statement about zero-initialisation as well.
I think that *modern* compilers in release mode are able to eliminate all additional copies in both situations (with and without user-defined copy ctor). Although I think that *old* compilers feel better w/o user-defined copy ctor (i.e. are able to eliminate more temporary objects).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"Why is it a bug?" Because it involves copy construction.
Perhaps we have been here before, but do you or does anyone know when additional copies can be generated in a way that might interfere with the user's intentions?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And what is the meaning of "such constructors could lead to accidental introduction of compiler temporaries" in the Reference Manual (I don't see how not defining a constructorwould preventthat). It might be nice to have a statement about zero-initialisation as well.
I agree about the bug. Every other copy assignment including void*takes the right-hand argument by reference. It will not really lead to any issue on architectures where machine word store and load is atomic; nevertheless we should make it right.
The reference was fixed, but might be not yet updated at the TBB site. Now it says:
The copy constructor is not atomic because it is compiler generated. Introducing any non-trivial constructors might remove an important property of atomic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Perhaps we have been here before, but do you or does anyone know when additional copies can be generated in a way that might interfere with the user's intentions?
In case of tbb::atomic copy construction, it will break atomicity for e.g. 64-bit types on 32-bit architecture. Does it answer your question, or you asked for something different?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think you are confusing term 'zero-initialized'. 'Zero-initialized' is a defined term in ISO C++, which refers to some forms of initialization like initialization of objects with static storage duration AND ALSO to initialization of primitive object members provided that object is declared with empty parenthesis, i.e. "()".
This means that tbb::atomic<>'s value MUST BE '0', if atomic is declared like:
tbb::atomic
Thats how I interpret Reinders' statement "You can rely on zero initialization to initialize an atomic
Yes, this is what was confusing me. When the book used the term "zero-initialized", I assumed it meant the standard's definition of the term. If I'm reading things right, it sounds like my assumption was correct and I was simply bitten by a compiler deficiency?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My question is not about why such copies subvert atomicity, but about a clarification of #13 (my question and Dmitriy's answer), i.e., when may they unintentially occur? (Perhaps it's clearer to disregard "in a way that might interfere with the user's intentions".)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"Why is it a bug?" Because it involves copy construction.
Perhaps we have been here before, but do you or does anyone know when additional copies can be generated in a way that might interfere with the user's intentions?
I think I start getting your point. You mean that load from source object will NOT be atomic nor acquire. Right? I was confused by your statement that it's not Ok to declare assignment operator as receiving operand by value.
If assignment operator assumed to make atomic load acquire from source operand, then yes, receiving operand be value will break that guarantee.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In case of tbb::atomic copy construction, it will break atomicity for e.g. 64-bit types on 32-bit architecture. Does it answer your question, or you asked for something different?
Assignment operator have to make load *acquire* from source operand, so it will also break on Itanium platform.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page