[m-rev.] for review: [PATCH 1/4] Add thread_safe attribute to store procedures.

[Julien Fischer]

On Tue, 22 Jul 2014, Peter Wang wrote:

> The mutvar procedures are not truly thread-safe but neither does
> obtaining a global lock make them become thread-safe in a useful way,
> except perhaps avoiding data races.  On the other hand, the global lock
> inhibits parallelism in programs that do use mutvars in a thread-safe
> manner.

The only ones that are not thread safe are those that are attached to
the I/O state since that is the only store state that can be split by a
call to spawn.  IMO, arranging for thread safe access to I/O mutvars is
the programmer's reponsibility -- as Paul said, there should be a a
prominent note about this in the documentation.  This is fine by me
otherwise.

On a related note: I've been using the impure mutvar module in the
standard library quite a bit -- how does everyone feel about making that
into a publicly documented part of the standard library (after a
suitable documentation cleanup)?

Cheers,
Julien.