<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 8:37 AM, Paul Bone <span dir="ltr"><<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Jul 23, 2014 at 01:22:50AM +1000, Julien Fischer wrote:<br>
><br>
> On Tue, 22 Jul 2014, Peter Wang wrote:<br>
><br>
>> The mutvar procedures are not truly thread-safe but neither does<br>
>> obtaining a global lock make them become thread-safe in a useful way,<br>
>> except perhaps avoiding data races.  On the other hand, the global lock<br>
>> inhibits parallelism in programs that do use mutvars in a thread-safe<br>
>> manner.<br>
><br>
> The only ones that are not thread safe are those that are attached to<br>
> the I/O state since that is the only store state that can be split by a<br>
> call to spawn.  IMO, arranging for thread safe access to I/O mutvars is<br>
> the programmer's reponsibility -- as Paul said, there should be a a<br>
> prominent note about this in the documentation.  This is fine by me<br>
> otherwise.<br>
<br>
</div>You're right. since stores use di/uo modes this is a moot point.  </blockquote><div><br></div><div>No, it's a valid concern for I/O mutvars, just not the others.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Of course<br>
someone can use a uniquness cast to create trouble for themselves but that's<br>
not a new problem.)<br></blockquote><div><br></div><div>The uniqueness casts do have "unsafe_" in their names for a reason ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> On a related note: I've been using the impure mutvar module in the<br>
> standard library quite a bit -- how does everyone feel about making that<br>
> into a publicly documented part of the standard library (after a<br>
> suitable documentation cleanup)?<br>
<br>
</div>I'm fine with that, the usual story applies about putting a large notice<br>
above it about thread safety, in addition to the impurity as the mutvar<br>
operations themselves arn't thread safe.</blockquote><div><br></div><div>Sure. </div><div><br></div><div>Cheers,</div><div>Julien.</div><div><br></div><div> </div></div><br></div></div>