AVR-Chat

Group,

In my opinion still, Don Kinzer's posts on where to use the volatile qualifier are unassailable and Bob Paddock's disagreement, "Volatile is never the solution to a problem with threads", is without merit.  Read on if you have the stomach for it.

Bob,

You write "I stand by what I said." and then write "Volatile always needs to be used appropriately, threads or no threads.".  This is not what you previously wrote.  If this is what you wish you had wrote, we're done here.

You write "I fail to see how John [Regehr] and company are wrong".  They are wrong by counter-example.  They propose that "volatile is almost useless for multi-threaded programming".  It isn't hard to be successful in multi-threaded programming design problems using only volatile and, to make the point, I provided an example.

You write "A ISR() changing a value ... to me is not a 'thread'".  I don't know why you bring this up.  The distinction is arbitrary and does not help the argument.  If you have a mechanism to safely pass data to and from interrupt threads, then you can use it between other types of execution threads as well, including multi-processor and DMA.

You quote ISO/IEC 9899:201x.  Footnote 134) says one of the things that Don says and does not support your argument.  You offer no support for your *new* argument that "There are places where applying 'volatile' blindly will produce code that is broken", although, depending on your definition of "broken", I could agree with you or not.  Again, this has no relevance to your previous argument that "Volatile is never the solution to a problem with threads".

You write "There is more than just adding 'volatile' on a variable or register to make bug free code".  Of course.  Nobody has said otherwise.  You must also design good algorithms, express them correctly in your chosen language, have a reliable compiler, etc, etc.

You write "So the argument is to blindly apply volatile?".  Now your post is looking like an attack, because this is certainly not the argument.  Don has written that the "volatile attribute must be used" on certain variables and goes on to explain how to figure out whether a variable should be volatile, with examples.  So the argument is precisely not what you claim it is, rather it is to apply volatile with your eyes open.

You quote ISO/IEC 9899:201x again.  Footnote 111 is taken entirely out of context.  In the paragraph that references the footnote, the document states that an assignment expression has a value (which, as we know, can be used as an rvalue in another assignment, or as a function argument, etc.).  It says that the value of the assignment expression is what has been stored in the object referenced by the left operand, which is kind-of obvious, but has to be said.  The footnote merely says that if the compiler needs the expression value, it can either read back the value of that object or just remember what it stored there and carry on.  (I would argue that if the object is volatile, the specification should pick one or the other and not leave this open as the read-back could have side-effects.  This is an area where the incomplete specification of the language can trip you up, but is easily avoided by not using the values of assignment expressions when the object referenced by the left operand is volatile.)

With regard to my "example of passing data between threads of execution using *only* the volatile qualifier", you write "Herb Sutter covers exactly this example in ...".  Well, this is a demonstrably false statement.  If you read only as far as page 2 of the article, you can see that the only thing that my example and the subject of the article have in common is the goal of passing data between producer and consumer threads.  You seem again to be more interested in discrediting me that supporting your argument.

In discussing my example, you write that counter access "must be *explicitly* atomic, unless the counters are uint8_t on our 8-Bit AVR's".  Well, on an 8-bit machine, they would naturally be 8 bits because that is the machine word size, so access to an 8-bit object is inherently atomic, as I required, and your comment is not helpful.  You describe the use of integer counters, the fact that the C language requires an integer to be at least 16 bits and the consequence that access to a 16-bit counter is not inherently atomic on an 8-bit machine and so the technique I have described will not work.  You are correct, but since I never said that it would work unless "counters ... [are] of a type such that access ... is inherently atomic" you again give the appearance of disagreeing with me without actually engaging my argument.

I'm done here, so, Bob, you may have the last word.

Graham Davies
ECROS Technology
www.ecrostech.com