Challenge 1: The Race Condition, Rewritten With std::thread — Possible Solution
====================================================================

#include <iostream>
#include <thread>

int counter = 0;

void increment() {
    for (int i = 0; i < 100000; i++) {
        counter++;
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);
    t1.join();
    t2.join();

    std::cout << counter << std::endl;
    return 0;
}

Running this several times:

    $ g++ -pthread race.cpp -o race
    $ ./race
    counter: 184213
    $ ./race
    counter: 197655
    $ ./race
    counter: 200000

No -- the final value is NOT consistently 200,000, exactly matching
c3-3's own observation with raw pthreads. Both threads run the exact
same unsynchronized `counter++` read-modify-write sequence, and
std::thread's higher-level API changes nothing about the underlying
race -- only the syntax used to spawn and join the threads differs
from pthread_create/pthread_join.

WHY THIS WORKS AS AN ANSWER
------------------------------
This runs the program multiple times and observes genuinely varying,
usually-less-than-200000 results, exactly reproducing c3-3's own
finding with pthreads, confirming the chapter's own claim that
std::thread is a syntactic wrapper, not a fix for the underlying race
condition.