Does int sum = func(1) + func(2) cause undefined behavior if func() modifies a global variable

Question

Inspired by this SO post, I am wondering whether the below snippet causes UB as both add_func() and mul_func() could modify counter concurrently and in an unspecified order:

int counter = 0;

int mul_func(int x) {
  counter *= x;
  x = counter;
  return x;
}

int add_func(int x) {
  counter += x;
  x = counter;
  return x;
}

int main(void) {
  int sum = add_func(3) + mul_func(2);
}

If so, does it help if I add mutex to them?:

int counter = 0;

pthread_mutex_d mtx;

int mul_func(int x) {
  pthread_mutex_lock(&mtx);
  counter *= x;
  x = counter;
  pthread_mutex_unlock(&mtx);
  return x;
}

int add_func(int x) {
  pthread_mutex_lock(&mtx);
  counter += x;
  x = counter;
  pthread_mutex_unlock(&mtx);
  return x;
}

int main(void) {
  pthread_mutex_init(&mtx);
  int sum = add_func(3) + mul_func(2);
  pthread_mutex_destroy(&mtx);
}

While the result can be non-deterministic (as the case of many multi-threading procedures), does the "unsequenced" nature still cause UB even if there is no data race?

Answer 1

It is indeed up to the compiler do decide the order in which it wants to call your functions. It will call both before the addition, but that's about all you know.

Your mutex doesn't do anything; these are for synchronizing threads, not forcing your compile to evaluate things in the order you want it. You code doesn't do things in parallel, it just does it in unspecified order.

The correct way to enforce an ordering would be something like

const int left=add_func(3);
const int right=mul_func(2);
int sum=left+right;

That way, the compiler has no choice but to call the functions in the order you're providing.

Update: so, as suggested in one of the comments, let me emphasize the wording a bit. Your code is not "undefined behavior" as per language definitions; you're actually getting one of two possible results, which are very well defined: one result appears if the compiler decides to call add_func first and mul_func second, while the other appears if the compiler likes the other calling order better.

The order in which the two functions are called is "unspecified", but they are always called one after the other, never in parallel. Any optimization that the compiler or the CPU might add that introduce some degree of parallelism will not change that; you'll always get one of the two possible results.

Just think about it from a different angle: if the compiler (or the CPU, or god) would add some random parallelism that would require YOU to take certain precautions, such unexpected changes to program behavior would break every software. There is a reason why optimizations always use terminology like not changing "observable behavior".

And yes, C++ allows certain optimizations to change "observable behavior", but that's explicitly laid out in the language specification, and not something that a compiler (or CPU) would just do on a whim.