That said, you can still have a data race with "immutable" data at the thread level as well.
For example, we have a system which has A processing threads, whose results are collated by the master and passed to a set of B processing threads. All of these threads use message passing and an immutable view of the master's environment which determines their behavior.
A command comes in which changes the master's environment, and the master sends the A and B threads a "die" command and waits for the flow of data out of the threads to stop. It then spins up new A threads and B threads to process the data with the new environment.
The data race appears when some old A threads become blocked on some external resource or are just unlucky in scheduling, passing data based off of outdated assumptions to the new B processors will be attempting to process data from the original A threads which have the wrong view of data.
The solution in this case is obvious - set up new queues, or more authoritatively kill off old threads, or change a parameter in the messages being passed, or pass the entire state from thread to thread, or... but the solutions to the problems outlined in the OP are also obvious, once the race condition is identified.
The default should be message passing concurrency, as Go advocates -- which of course can be done with simple threads and queues. Unfortunately in C++ that leads to tricky memory management issues.