[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