2 questions: atomic as a fence + typo

2 questions: atomic as a fence + typo

Hi. I have 2 questions.

1) Atomic as a fence. Writing to an atomic variable has release semantics, e.a. operations before the atomic assigment never move over it. Can I use atomic variables as a fence? Is there any guarantee that compiler won't optimize out the unuzed atomic variable in the following code fragment? Should I qualify it as volatile?

T* ptr;
ptr = new T(...);
tbb::atomic ptr_atomic;
ptr_atomic = ptr;
 Past this point ptr should be pointing to
 the fully constructed instance of T. Right?

2) Looks like there is a typo in the Tutorial, Chapter 8, Table 13.
x.fetch_and_store(y) does x=y, not y=x.

Thank you,

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Why wouldn't you instead load/acquire the fully constructed instance of T from the same atomic, eliminating ptr except perhaps for local use?

Do you mean something like this

tbb::atomic ptr_atomic;
ptr_atomic = new T(...);
 past this point ptr_atomic points to the fully
 constructed instance of T. We can signal all other
 threads that it is OK to use ptr_atomic.

That would work. But the rest of the code uses plain pointers. I can only make the pointer to point to an instance of T.

In another thread you can pass around a plain pointer after you have read it from the atomic. Would that work?

Yes it would work. I probably recode the whole thing to use atomic variables. Is there any performance penalty for using atomic pointers instead of plain pointers?

tbb::atomic ptr_atomic;
T* ptr;
T t;

*ptr_atomic = t;
// vs
*ptr = t;
 any performance difference?

Don't replace those plain pointers: use the atomics only for synchronisation moments.

That makes sense. I changed my code to use atomic to send a message and left the plain pointers unchanged. Looks like everething works well.

Leave a Comment

Please sign in to add a comment. Not a member? Join today