[MLton] Re: Real*.gdtoa not thread safe

Matthew Fluet fluet at cs.cornell.edu
Mon Aug 28 17:56:28 PDT 2006


> It really is sad to have to worry about this kind of stuff,  and  I  am  sure
> that there must be many other places where this needs to be done.

I wonder how hard and useful it would be to implement one of the static 
race detection analyses for Standard ML.

> I  tested  things  and  I couldn't perceive any slow down, but in more light-
> weight  cases,  we  could  make  One.use  REALLY  cheap   by   avoiding   the
> Primitive.Thread.atomic{Begin, End} by having the following test-and-set kind
> of primitive:
>    val fetchAndUpdate: 'a ref * 'a -> 'a
> which atomically fetches the old contents  and  stores  the  provided  value,
> returning the old value.
>
> The point is that (I am pretty sure) that that code would be `atomic' because
> there are no safe points in it any way.

Sure, especially if we implement the primitive (using the separate fetch 
and update prims) after the limit-check insertion pass.  Of course, that 
only works for many ML threads mapped to one system thread.



More information about the MLton mailing list