[MLton] threads and traces

[Matthew Fluet]

> I am examining the possibility of creating a tracing utility for
> multi-threaded programs (ie creating some sort of barrier for reads and
> writes to shared objects, context switch points, locks and unlocks, in
> mlton's case atomic begin/end.). Unfortunately I dont seem to be able to
> find much documentation on the mlton scheduler/multi-threaded support.
> From the user guide, it seems like I will have to code up my own
> scheduler.

That's true.  MLton doesn't impose any particular scheduler on threads.
You can easily code up a non-preemptive scheduler.  A preemptive scheduler
generally needs signals and the OSs signals.  You might be able to get by
with a scheduler that gets runs based on a GC signal (which we could
expose, or you can probably get something to work by attaching the
scheduler as the finalizer to an object).

> Any ideas where best to imbed the barriers? For that matter,
> should this type of utily extend the main compiler or the profiler,
> opinions?

Could you describe more of what you hope to do?  You might look at
 /lib/cml/util/{assert,critical,debug}.{sig,sml}
in the mlton sources, which was all I needed to debug the CML
implementation.  But, certainly, that doesn't scale well to debuging CML
programs.

Right now, the Basis Library isn't thread safe.  More to the point, the
Basis Library rarely uses atomicBegin/End.  So, anyone wanting to write a
multi-threaded program will probably end up doing a lot of
atomicBegin/Ends in their own program, or at least writing a Basis Library
wrapper to do the atomicBegin/Ends.  That probably means that you could
provide a tracing utility as a module/library.  As long as the user's
program made atomicBegin/End calls through your program, you would see
them and trace them.  That will miss some calls that are in the Basis
Library, but those are pretty obscure.  Note that in entering and exiting
the runtime system when switching threads, there are some implicit
atomicBegin/Ends, so those are never in ML code.