> Whenever you consider parallelization in computer science, there is a potential for "race condition" problem. Since there's specific reference to Computer Sc

> Whenever you consider parallelization in computer science, there is a potential for "race condition" problem. Since there's specific reference to Computer Science, I feel compelled to point out that race conditions arise from concurrency, not "parallelization" (parallelism). Making a deterministic job concurrent can make it nondeterministic. Making a deterministic job parallel can't. If your job's already nondeterministic, concurrency and parallelism won't change that. For example, on a machine with a single processor running multiple jobs concurrently, different scheduling/interleaving of those jobs can lead to races, without any parallelism being involved. Looking at it another way, doing a job in parallel can't introduce a race condition. A job with a race condition is semantically different from a race-free job, regardless of whether they're executed in serial or parallel. There are many ways to change the semantic meaning of a line of code; one way is to change the characters which make up that line; another is to change which programming language is used to evaluate it. There are large semantic differences between, say, the "Java" language and the "Java with threads" language. See also https://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/ https://existentialtype.wordpress.com/2011/03/17/parallelism...