I’ve simply wondered, if such optimization is safe
against all such illegal traps, but it seems it really is!
It’s only hard to get used to.

On the other hand isn’t it funny - gcc enforces people to respect C’s single threadedness just when they are
about to forget single processor boxes!

Thanks very much for these great programming articles!

But, doesn’t the standard say anything about flow control?
Eg., can something like this:
if (sin(x) == 2.0)
acquires_count = ++acquires_count/0;

be turned to this as well?:
r = sin(x) == 2.0;
acquires_count = (acquires_count += r == 0)/0;

But, doesn’t the standard say anything about flow control?
Eg., can something like this:
if (sin(x) == 2.0)
y = ++acquires_count/0;

be turned to this as well?:
r = sin(x) == 2.0;
y = (acquires_count += r == 0)/0;

if (pthread_mutex_trylock (&m) == 0)
++acquires_count;

gcc turned it into

r = pthread_mutex_trylock (&m);
acquires_count += r == 0;

(gcc generated an add with carry flag to memory, which is a standard x86 instruction). A load and store were effectively added in the implicit else branch of the conditional, but no loads or stores were moved over the call to pthread_mutex_trylock.

tmp = acquires_count;
res = pthread_mutex_trylock(&mutex);
acquires_count = tmp + (res == 0)

and as somebody else noted, under POSIX threads, moving the load across the pthread_* call is not allowed. Everybody writing from Gcc says acquires_count should have been declared volatile. It seems to me that the pthread call should have an attribute forbidding the compiler from moving memory operations across it. I’m astonished there isn’t such an attribute. It seems to me it’s needed for practically every synchronization primitive.