“Is Parallel Programming Hard, and, If So, What Can You Do About It?” v2 Is Out
Counterpoint: Parallel programming isn&#x27;t very hard.<p>Seriously: try fork() + wait(), or spawn in bash &#x2F; cmd line. make -j offers parallelism (and Ninja is &quot;make -j by default&quot;).<p>OpenMP&#x27;s &quot;#pragma omp parallel for&quot; is extremely easy to use.<p>Things get harder with thread libraries, but the &quot;parallelism&quot; part of pthreads is pretty easy. pthread_create(&amp;thread_id, NULL, function, args);, at least if you&#x27;re fine with the default settings.<p>C++ Threads are even easier than pthreads.<p>-----------<p>The hard part is:<p>1. Communication &#x2F; Synchronization -- But really, condition variables are the most complicated thing most people need. fork() + wait() push the difficult communication part to the wait() or to pipes. But if you stick with wait() &#x2F; waitpid() as your main communication mechanism, its pretty easy to think about.<p>2. High performance programming -- This is just hard, especially if you begin to reach for the highest performance &quot;memory barrier &#x2F; lock-free programming&quot; styles. This is where &quot;false sharing&quot; comes in (your code correctly executes under false sharing, but slowly due to how the L1 cache handles multicore architectures).<p>---------<p>However, if you stick with a simple fork-join communication model (ex: pthread_join, or wait()&#x2F;waitpid() based synchronization)... its really not too hard at all. Just try to stay away from the high-performance techniques unless you really need them.