A threading riddle

<p><pre><code> import Control.Concurrent.STM import Control.Monad import Data.Vector type VecInts = Vector (TVar Int) newVecInts :: Int -&gt; STM (VecInts) newVecInts s = generateM s (\_ -&gt; newTVar 0) modifyVI :: VecInts -&gt; Int -&gt; Int -&gt; STM () modifyVI vi pos val = do writeTVar (vi ! pos) val waitUntilEqual :: VecInts -&gt; Int -&gt; Int -&gt; STM () waitUntilEqual vi p1 p2 = do a &lt;- readTVar (vi ! p1) b &lt;- readTVar (vi ! p2) when (a &#x2F;= b) retry</code></pre>

My c++ solution: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;anonymous&#x2F;7e6cc8f58e9cde1b6fda" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;anonymous&#x2F;7e6cc8f58e9cde1b6fda</a><p>I believe it follows all of the requirements. There is one glaring flaw which is that it uses a condition variable per &#x27;wait_until_equal&#x27; call, though it uses only N mutexes. So this doesn&#x27;t fall under the N^2 primitives (in the case of many waits), though its unclear to me if thats an official rule.<p>Im happy to listen to feedback or if someone sees an error.

This is an example of why I see node.js having more value in its single-threaded async architecture than in its capacity to use the same programming language on client and server.<p>More generally, when you discover a tricky problem that would make a good interview question, oftentimes there&#x27;s an architectural decision that would eliminate the problem.