CODEWITHSUNDEEP
c++multithreadingconcurrencymutexrace-condition
John Baltimore
John Baltimore

Reputation: 97

Question regarding race conditions while multithreading

So I'm reading through a book an in this chapter that goes over multithreading and concurrency they gave me a question that does not really make sense to me.

I'm suppose to create 3 functions with param x that simply calculates x * x; one using mutex, one using atomic types, and one using neither. And create 3 global variables holding the values. The first two functions will prevent race conditions but the third might not.

After that I create N threads and then loop through and tell each thread to calculate it's x function (3 separate loops, one for each function. So I'm creating N threads 3 times)

Now the book tells me that using function 1 & 2 I should always get the correct answer but using function 3 I won't always get the right answer. However, I am always getting the right answer for all of them. I assume this is because I am just calculating x * x which is all it does.

As an example, when N=3, the correct value is 0 * 0 + 1 * 1 + 2 * 2 = 5.

this is the atomic function:

void squareAtomic(atomic<int> x)
{
    accumAtomic += x * x;
}

And this is how I call the function

thread threadsAtomic[N]
for (int i = 0; i < N; i++) //i will be the current thread that represents x
    {
        threadsAtomic[i] = thread(squareAtomic, i);
    }

    for (int i = 0; i < N; i++)
    {
        threadsAtomic[i].join();
    }

This is the function that should sometimes create race conditions:

void squareNormal(int x) 
{
    accumNormal += x * x;
}

Heres how I call that:

thread threadsNormal[N];
    for (int i = 0; i < N; i++) //i will be the current thread that represents x
    {
        threadsNormal[i] = thread(squareNormal, i);
    }

    for (int i = 0; i < N; i++)
    {
        threadsNormal[i].join();
    }

This is all my own code so I might not be doing this question correctly, and in that case I apologize.

Upvotes: 0

Views: 243

Answers (1)

Jeremy Friesner
Jeremy Friesner

Reputation: 73041

One problem with race conditions (and with undefined behavior in general) is that their presence doesn't guarantee that your program will behave incorrectly. Rather, undefined behavior only voids the guarantee that your program will behave according to rules of the C++ language spec. That can make undefined behavior very difficult to detect via empirical testing. (Every multithreading-programmer's worst nightmare is the bug that was never seen once during the program's intensive three-month testing period, and only appears in the form of a mysterious crash during the big on-stage demo in front of a live audience)

In this case your racy program's race condition comes in the form of multiple threads reading and writing accumNormal simultaneously; in particular, you might get an incorrect result if thread A reads the value of accumNormal, and then thread B writes a new value to accumNormal, and then thread A writes a new value to accumNormal, overwriting thread B's value.

If you want to be able to demonstrate to yourself that race conditions really can cause incorrect results, you'd want to write a program where multiple threads hammer on the same shared variable for a long time. For example, you might have half the threads increment the variable 1 million times, while the other half decrement the variable 1 million times, and then check afterwards (i.e. after joining all the threads) to see if the final value is zero (which is what you would expect it to be), and if not, run the test again, and let that test run all night if necessary. (and even that might not be enough to detect incorrect behavior, e.g. if you are running on hardware where increments and decrements are implemented in such a way that they "just happen to work" for this use case)

Upvotes: 2

Related Questions