<div dir="ltr"><br><br>
<div class="gmail_quote">On Mon, Sep 8, 2008 at 8:33 PM, Bruce Eckel <span dir="ltr">&lt;<a href="mailto:bruceteckel@gmail.com">bruceteckel@gmail.com</a>&gt;</span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">As some of you on this list may know, I have struggled to understand<br>concurrency, on and off for many years, but primarily in the C++ and<br>
Java domains. As time has passed and experience has stacked up, I have<br>become more convinced that while the world runs in parallel, we think<br>sequentially and so shared-memory concurrency is impossible for<br>programmers to get right -- not only are we unable to think in such a<br>
way to solve the problem, the unnatural domain-cutting that happens in<br>shared-memory concurrency always trips you up, especially when the<br>scale increases.<br><br>I think that the inclusion of threads and locks in Java was just a<br>
knee-jerk response to solving the concurrency problem. Indeed, there<br>were subtle threading bugs in the system until Java 5. I personally<br>find the Actor model to be most attractive when talking about<br>threading and objects, but I don&#39;t yet know where the limitations of<br>
Actors are.<br><br>However, I keep running across comments where people claim they &quot;must&quot;<br>have shared memory concurrency. It&#39;s very hard for me to tell whether<br>this is just because the person knows threads or if there is truth to<br>
it. </blockquote>
<div>&nbsp;</div>
<div>For correctness, maybe not, for efficiency, yes definitely!</div>
<div>&nbsp;</div>
<div>Imagine a program where you have a huge set of data that needs to be modified (in some sense) over time by thousands of agents. E.g. a game simulation.</div>
<div>Now, also imagine that every agent could *potentially* modify every single piece of data, but that every agent *typically* only touches two or three varibles here and there. I.e. the collisions between the potential read/write sets is 100%, while the collisions for the actual read/write sets is very very low.</div>

<div>&nbsp;</div>
<div>How would you do this with threads and message passing? Well you could have one big thread owning all of your data that takes &quot;update&quot; messages, and then &quot;updates&quot; the world for you (immutably if you wish, by just replacing its &quot;world&quot; variable with a new one containing your update), but now you&#39;ve effectively serialized all your interactions with the &quot;world&quot;, so you&#39;re not really concurrent anymore!</div>

<div>&nbsp;</div>
<div>So you could decompose the world into multiple threads using some application-specific logical sudivision, but then you&#39;re effectively just treating each thread as a mutable variable with an implicit lock (with the risks of deadlock&nbsp;that comes with it - remember we don&#39;t know the read/write set in advance -&nbsp;it could be the entire world -&nbsp;so we can&#39;t just order our updates in some global way here), so you&#39;re really just doing shared mutable state again, and gain little from having threads &quot;simulate&quot; your mutable cells... </div>

<div>&nbsp;</div>
<div>What you really need for this is some way for each agent to update this shared state *in parallel*, without having to block all other agents pessimistically, but instead only block other agents if there was an *actual* conflict. STM seems to be the only real hope for that sort of thing right now.<br>
</div>
<div>IMO my list of preferred methods goes like this:</div>
<div>1. Purely functional data parallelism</div>
<div>2. Purely functional task parallelism (using e.g. strategies)</div>
<div>3. Message passing with no (or very minimal)&nbsp;shared state (simulated using threads as &quot;data servers&quot; or otherwise)</div>
<div>(3.5. Join patterns? Don&#39;t have enough experience with this, but seems sort of nice?)</div>
<div>4. Shared state concurrency using STM</div>
<div>5. Shared state concurrency using locks</div>
<div>6. Lockless programming.</div>
<div>&nbsp;</div>
<div>So while I wouldn&#39;t resort to any shared state concurrency unless there are good reasons for why the other methods don&#39;t work well (performance is a good reason!), there are still situations where you need it, and a general purpose language had better supply a way of accessing those kinds of facilities.</div>

<div>&nbsp;</div>
<div>-- <br>Sebastian Sylvan<br>+44(0)7857-300802<br>UIN: 44640862<br></div></div></div>