atomic boolean initializes to true?

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

Ok from the compiler front, I was checking on a totally unrelated error I was having, and found these bug reports about GCC.
My guess after reading them isatomic( atomic() ) Could be whatever the compiler wants it to be.

http://gcc.gnu.org/ml/gcc-bugs/2007-09/msg01606.html
http://gcc.gnu.org/ml/gcc-bugs/2006-10/msg00585.html

Quoting - robert.jay.gould

Ok from the compiler front, I was checking on a totally unrelated error I was having, and found these bug reports about GCC.
My guess after reading them isatomic( atomic() ) Could be whatever the compiler wants it to be.

http://gcc.gnu.org/ml/gcc-bugs/2007-09/msg01606.html
http://gcc.gnu.org/ml/gcc-bugs/2006-10/msg00585.html

Why you think so? Can you elaborate?

What I see is: temporary object is value-initialized, then it is copied to named object via copy constructor. So value of named object must be 0. Compiler can eliminate construction of temporary object and coping, but this doesn't affect result.

All about lock-free algorithms, multicore, scalability, parallel computing and related topics:
http://www.1024cores.net

"Sorry, I was looking at an earlier version of the C++ standard regarding initialisation; I'll check tonight whether I overlooked value-initialisation or whether it was added later." Value-initialisation was added later than in the 1998 version.

I didn't have a look at the current proposal for C++0x on Thursday after all, and on Halloween it got way too scary so I had to stop.

"All modifications to a particular atomic object M occur in some particular total order, called the modification order of M. If A and B are modifications of an atomic object M and A happens before (as defined below) B, then A shall precede B in the modification order of M, which is defined below." Abandon all hope, ye who enter here.

I'm sorry, but I'm still an adapt of the dictum "Ce qui se conoit bien s'nonce clairement, et les mots pour le dire arrivent aisment." Maybe it's just the editor who is not doing his job, but I do get an uneasy feeling about this. I'm not disinterested to know where C++ is going with this, so why should reading about it be a struggle that I only want to postpone, which is not the case with other parts of the standard? Why should it all be so convoluted if the subject is clear in the minds of the authors (and it had better be...)? Is it just me?

Quoting - Raf Schietekat

I didn't have a look at the current proposal for C++0x on Thursday after all, and on Halloween it got way too scary so I had to stop.

"All modifications to a particular atomic object M occur in some particular total order, called the modification order of M. If A and B are modifications of an atomic object M and A happens before (as defined below) B, then A shall precede B in the modification order of M, which is defined below." Abandon all hope, ye who enter here.

I'm sorry, but I'm still an adapt of the dictum "Ce qui se conoit bien s'nonce clairement, et les mots pour le dire arrivent aisment." Maybe it's just the editor who is not doing his job, but I do get an uneasy feeling about this. I'm not disinterested to know where C++ is going with this, so why should reading about it be a struggle that I only want to postpone, which is not the case with other parts of the standard? Why should it all be so convoluted if the subject is clear in the minds of the authors (and it had better be...)? Is it just me?

I think because... it's just hard in itself. Do you have a better to way to unify memory ordering, atomic operations and memory fences of all wide-spread hardware?

Personally I am thinking that they have done great work.

All about lock-free algorithms, multicore, scalability, parallel computing and related topics:
http://www.1024cores.net

"Do you have a better to way to unify memory ordering, atomic operations and memory fences of all wide-spread hardware?" Can you guarantee that it gets in the final version instead of what they have now?

Quoting - Raf Schietekat

"Do you have a better to way to unify memory ordering, atomic operations and memory fences of all wide-spread hardware?" Can you guarantee that it gets in the final version instead of what they have now?

I can guarantee that it will not get into final version :) But it will be valuable in itself!

Well, I argue that current definitions are sufficiently reasonable. Can you come up with anything better? If no, then this confirms my point. No?

All about lock-free algorithms, multicore, scalability, parallel computing and related topics:
http://www.1024cores.net

"I can guarantee that it will not get into final version :) But it will be valuable in itself!" But going to see the new Bond instead will be so much more fun.

"Well, I argue that current definitions are sufficiently reasonable. Can you come up with anything better? If no, then this confirms my point. No?" It would be too much work just to prove a point.

Pages

Leave a Comment

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