<div dir="ltr"><div>Hi Madan,</div><div><br></div>Yes, GHC, like Java, is an "unsafe language" currently ;-). It does not protect its abstractions against buggy programs. Namely both Haskell and Java do not protect semi-colon/(>>).<div><br></div><div>Really, we should probably have some additional monad to distinguish data-race-free (DRF) IO programs from other IO programs that may have data races.</div><div><br><div>Or we could just make sequential consistency the law of the land for IO, as you propose. One thing I'd really like to work on -- if someone were interested in collaborating -- is testing the overhead of making sequential composition the norm in this way.</div><div><br></div><div>I had a nice conversation with your SNAPL co-author Satish about this recently. It seems like we could survey a broad swath of Haskell code to see if fine-grained use of "writeIORef" and "readIORef" are at all common. My hunch is that IORefs used in concurrent apps (web servers, etc), all use atomicModifyIORef anyway.</div><div><br></div><div>Thus like you I think we could fence read/writeIORef with acceptable perf for most real apps. You can still have "reallyUnsafeReadIORef" for specific purposes like implementing concurrent data structures.</div><div><br></div><div>Best,</div><div> -Ryan</div><div><br></div></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 10:06 AM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Maclan<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I’m glad you enjoyed the awkward squad paper.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I urge you to write to the Haskell Café mailing list and/or ghc-devs. Lots of smart people there. Ryan Newton is working on this kind of stuff; I’ve cc’d him.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">But my rough answer would be: IORefs are really only meant for single-threaded work. Use STM for concurrent communication.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">That’s not to say that we are done! The Haskell community doesn’t have many people like you, who care about the detail of the memory model. So please do help us
</span><span style="font-size:12.0pt;font-family:Wingdings">J</span><span style="font-size:12.0pt">. For example, perhaps we could guarantee a simple sequential memory model without much additional cost?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Madan Musuvathi
<br>
<b>Sent:</b> 11 March 2016 19:35<br>
<b>To:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
<b>Subject:</b> Semantics of IORefs in GHC<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-US">Dear Simon,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I really enjoyed reading your <a href="http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf" target="_blank">
awkward squad paper</a>. Thank you for writing such an accessible paper. <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">My current understanding is that the implementation of IORefs in GHC breaks the simple semantics you develop in this paper. In particular, by not inserting sufficient fences around reads and writes of IORefs, a Haskell
program is exposed to the weak-memory-consistency effects of the underlying hardware and possibly the backend C compiler. As a result, the monadic bind operator no longer has the simple semantics of sequential composition. Is my understanding correct?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">This is very troublesome as this weaker semantics can lead to unforeseen consequences even in pure functional parts of a program. For example, when a reference to an object is passed through an IORef to another thread,
the latter thread is not guaranteed to see the updates of the first thread. So, it is quite possible for some (pure functional) code to be processing objects with broken invariants or partially-constructed objects. In the extreme, this could lead to type-unsafety
unless the GHC compiler is taking careful precautions to avoid this. (Many of these problems are unlikely to show up on x86 machines, but will be common on ARM.)<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I am sure the GHC community is addressing these problems one way or the other. But, my question is WHY? Why can’t GHC tighten the semantics of IORefs so that the bind operation simply means sequential composition? Given
that Haskell has a clean separation between pure functional parts and “awkward” parts of the program, the overheads of these fenced IORefs should be acceptable. <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">My coauthors and I wrote a recent <a href="http://research.microsoft.com/apps/pubs/default.aspx?id=252150" target="_blank">
SNAPL article</a> about this problem for other (“less-beautiful” </span><span lang="EN-US" style="font-family:Wingdings">J</span><span lang="EN-US">) imperative languages like C# and Java. I really believe we should support sequential composition in our programming
languages. <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">madan<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</div>
</div>
</blockquote></div><br></div></div>