<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 3:58 PM, 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:16:54PM +1000, Julien Fischer wrote:<br>
> On Wed, Jul 23, 2014 at 8:37 AM, Paul Bone <<a href="mailto:paul@bone.id.au">paul@bone.id.au</a>> wrote:<br>
><br>
> > 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>
> > You're right. since stores use di/uo modes this is a moot point.<br>
><br>
><br>
> No, it's a valid concern for I/O mutvars, just not the others.<br>
<br>
</div>I thought I was trying to agree with you.  I'm now confused but nevermind<br>
that.<br></blockquote><div><br></div><div>It simple enough:</div><div><br></div><div>- thread safety is an issue for mutvars attached to the I/O state because</div><div>  the I/O state can be split by a call to spawn and in principle both threads</div>
<div>  can access the mutavar.</div><div><br></div><div>- thread safety is not an issue for mutvars attached to other states since</div><div>  the states must be unique and cannot be split by a call to spawn.</div><div>  (The inst of the closure passed to spawn prevents this.)</div>
<div><br></div><div>Cheers,</div><div>Julien.</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div></div></div>