Article on `volatile` C Keyword

Joe Nelson joe at
Sat Feb 6 18:32:28 UTC 2021

Chris Wilson wrote:
> I thought that this was an interesting article. In it, the author
> explains how C is described with reference to an abstract machine
> (something that Joe's explained to me in the past). I thought others
> here may enjoy it:

Thanks for the link, great article. Just got around to reading it.

I thought it made a good point about the volatility of a pointer vs
where it points. Perhaps this subtlety motivated named-register
storage-class specifiers in ISO/IEC technical report 18037 (Extensions
to support embedded processors). That proposal would allow you to alias
specific registers with variables using implementation-defined names,
rather than pointing to magic addresses.

For example, the snippet to read the Timer/Counter 1 register (TCNT1)

	#define TCNT1 (*(volatile uint16_t *)(0x4C))
	uint16_t first = TCNT1;
	/* ... */
	uint16_t second = TCNT1;

could become something like this, assuming the implementation offers _TCNT1:

	register _TCNT1 volatile uint16_t timer;
	uint16_t first = timer;
	/* ... */
	uint16_t second = timer;

The article also mentions using volatile for visibility between threads.
Maybe that suggestion is more relevant for kernel code?  AFAICT,
application code using a library like pthreads doesn't need volatile.
Butenhof's book _Programming with POSIX Threads_ mentions in section 3.4
"Memory visibility between threads" that values one thread can see can
also be seen by another thread synchronizing with it.

POSIX specifies these functions as having the memory fencing property:

Now to be honest, I am unclear how the compiler knows that a thread
waking up from say, pthread_cond_wait, needs to reload a variable on
read rather than making an "optimization." I would assume you'd need to
mark the variable volatile in conjunction with pthread synchronization,
but somehow the compiler knows better and you don't? Can anyone shed
some light on that?

More information about the Friends mailing list