I think the point is that he didn't know there was a lock. His closing argument seems to be that when you're writing muli-threaded code, you have to not only think about what your own code is doing, but also about what all the library and system calls you use are doing. Which is one of the many reasons multi-threaded code is harder to write than single threaded.
Yes, I thought rand()'s self-locking was pretty common knowledge, but it is a good example to teach the perils of multithreading because its signature gives no indication that anything bad will happen. strtok() is even worse.
C++11's excellent <random> library represents the PRNG as an object like it should. Besides making the statefulness of PRNGs explicit, its API encourages correct usage - it would be more work to share a PRNG between threads.
strtok() is even worse. (Because it has global state)
There are a lot of C standard library functions from the 1970s that should have been moved to a "deprecated" library around 1990 or so and phased out by now.
>I think the point is that he didn't know there was a lock.
One could argue that if you decide to go concurrent for performance reasons it's your responsibility to check for implicit locking behavior. Otherwise you're just doing cargo cult programming.
I think this is why the actor model, or CSP, is really nice, because it makes these things easier to reason about, and trace. In the actor model, you could dispatch the data to each thread and split up the processing.
I assume that you would want to run a tight loop in the actor? Otherwise, you will be spending much time sending messages, especially in a relatively cheap computation such computing the next number in a stream of pseudo-random numbers.
If the tight loop is in the actor (or process reading from a channel). You have the same problems again.
tl;dr: I don't see how the actor model helps here, it will either be slow or have the same problems (you should know what functions lock a data structure).
BTW, you can model a thread-safe random number generator without using a lock, replacing it with a CAS operation on a reference.
You still have problems this way, but at least it is non-blocking, in the sense that if the scheduler blocks any thread for any reason, then the other active threads can still have progress. And at least in Java, for a number of threads less or equal to the number of cores available, it will have better throughput, as locks these days are optimized for the common scenario of adding "just in case" synchronization (i.e. biased towards the thread that last acquired that lock), which hurts performance because of the extra management required.
