<br><br><div class="gmail_quote">2010/1/6 Michel Fortin <span dir="ltr"><<a href="mailto:michel.fortin@michelf.com">michel.fortin@michelf.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Le 2010-01-05 à 18:31, Álvaro Castro-Castilla a écrit :<br>
<div class="im"><br>
> Is there a way that to make this eventually generalizable to any<br>
> operation or groups of operations that should be performed atomically?<br>
><br>
> something like:<br>
><br>
> atomic {<br>
> ++x;<br>
> }<br>
><br>
> or even<br>
><br>
> atomic ++x;<br>
> atomic(++)x;<br>
<br>
</div>I proposed this earlier:<br>
<br>
++atomic(y)<br>
<br>
The idea is to create a function template "atomic" that would return a temporary struct. All operators defined for that struct would translate to atomic operations done on y, or memory barriers for read and writes.<br>
<div class="im"><br>
<br></div></blockquote><div><br><br>Well, of course that makes way more sense if its a function template :). I was referring to a compiler <br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> that would create a variable doing the work of "y", but in case you<br>
> want to specify the operations.<br>
><br>
> atomic {<br>
> int y = x;<br>
> y++;<br>
> x = y;<br>
> }<br>
<br>
</div>This syntax I don't like. While enclosing one operation in an atomic block is fine, here it looks as though all those actions are done in one atomic operation, which isn't at all the case. How hard is it to write this instead:<br>
<br>
int y = atomic(x);<br>
y++;<br>
atomic(x) = y;<br>
<br></blockquote><div><br><br>Just to clarify better what I meant:<br> atomic{} would be supported from the compiler for defining critical regions as transactions. It would group the whole transaction "atomicIncrement". I understand that generalizing this would be hard, or maybe not possible if you are calling functions inside that code. However, allowing only calling pure functions might be doable.<br>
<br>Anyway, I just pointed this thing out, because the whole debate heads to Message Passing as the main way to do concurrency in D, leaving traditional threads and especially Software Transactional Memory behind. But how easy/possible would be to implement as a library? (just a question) I guess threads will be kept, but STM is not being mentioned. My point is that there are situations where MP is not the best/easiest solution. For instance, for multi-agent simulations, you could think that MP would work well. However, when you want to visualize the simulation you need to duplicate the number of messages and send them to a central thread for processing the whole data and visualize it. With normal threading this would be the typical "dirty flag", stop the simulation and bring the data into the vis. thread; with STM you could just read a snapshot of the data and visualize it with no need for locks.<br>
<br>I would say:<br>classical threads -> message passing -> transactional<br>indicates a progression from more computational concept to more natural. This might be highly questionable, but I think of it as abstractions from the natural world. I could bore you a bit more with analogies and so on, but I must go back to work. What is clear at this point, however, is that we are not sure which one of those or other concurrency methods is going to prevail or coexist. Does D want to tie with MP only? or create the tools for various methods? At its least, I think it would be a good decision to keep MP with some possibilities for traditional threads. I'm a great supporter of MP, anyway (that's why I'm here).<br>
<br>Best Regards,<br><br>Álvaro Castro-Castilla<br>
</div></div>