CODEWITHSUNDEEP
multithreadingpthreadsschedulingrace-condition
Colin Sherland
Colin Sherland

Reputation: 31

Thread scheduling/Data race conditions

In class, we are studying threads and race conditions. By my estimates, it should be possible for the below code to output the value 8 or 9, as it is possible that thread 1 is interrupted by thread 2 before the counter value is updated, but after it has been incremented in the eax register.

int counter = 10;
  void *worker(void *arg) {
  counter--;
  return NULL;
}
int main(int argc, char *argv[]) {
  pthread_t p1, p2;
  pthread_create(&p1, NULL, worker, NULL);
  pthread_create(&p2, NULL, worker, NULL);
  pthread_join(p1, NULL);
  pthread_join(p2, NULL);
  printf("%d\n", counter);
}

However, when I run the code, I always receive the output 8. Is it a mechanism of the compiler that normalizes the output, or is it only possible for the code to output 8 (no race condition is created)?

Upvotes: 1

Views: 66

Answers (3)

Humphrey Winnebago
Humphrey Winnebago

Reputation: 1682

There definitely is a race condition. The reason you're not seeing it is because the increment happens so fast compared to the time it takes to start a thread that it's likely for the first thread to be done before the second thread even starts. You'll see the race condition if you make the amount of work sufficiently large that the first thread will still be running when the second one starts.

example: modify the worker function to decrement in a loop 

int counter = 1000000000;

void* worker(void *arg) 
{
  for (int i = 0; i < 500000000; ++i)
    --counter;
  return NULL;
}

Since counter starts at 1 billion, and you're running 2 threads that each decrement counter by 500 million, you would expect counter to be 0 when you are done if race conditions didn't exist.

Upvotes: 0

Jerry Coffin
Jerry Coffin

Reputation: 490048

The code definitely has a race condition.

I don't find it surprising that you're seeing consistent results--starting a thread takes a little while, so there's a good chance that in your case, the first thread finishes before the second gets started.

Nonetheless, the code clearly has undefined behavior, because there's no question it has a race condition.

Upvotes: 0

David Schwartz
David Schwartz

Reputation: 182753

There's no way for us to tell without knowing lots of complicated details about your platform, compiler, maybe even CPU. The code has a race condition in theory but it may be exceptionally difficult, maybe even impossible, to trigger.

Of course, if you upgrade your compiler or CPU, change compilation options, upgrade your OS, or do any number of other things, it may start behaving differently.

This is one of the reasons race conditions can be so insidious. They can be impossible to trigger under some conditions and then suddenly start happening all the time when some change is made elsewhere.

Upvotes: 1

Related Questions