[m-dev.] Globals and concurrency

Julien Fischer juliensf at csse.unimelb.edu.au
Tue Aug 1 18:13:42 AEST 2006


On Tue, 1 Aug 2006, Peter Wang wrote:

> Has there been any thought about how io.set_globals should behave in the
> presence of threads, i.e. should the effect of io.set_globals be
> reflected in other threads?

A thought I had a while ago is that now we have mutables and the
`attach_to_io_state' attribute we should just get rid of io.{set,get}_globals.

> The current input/output text/binary
> streams should be context-specific data (i.e. the Mercury analogue of
> thread-specific data) and it's easy enough for me to make globals
> context-specific as well.
>
> If io globals are not context-specific, then there should be a locking
> mechanism, otherwise code like:
>    io.get_globals(Globals0, !IO),
>    foo(Globals0, Globals),
>    io.set_globals(Globals, !IO),
>
> is not thread-safe.

I presume the problem here is that the existing locking mechanisms are
in the wrong spot, i.e they are attached to the access preds rather than
the global (so while two threads cannot simultaneously call io.get_globals,
two threads could simultaneously call io.get_globals and io.set_globals)?

It would seem that mutable declarations also have this problem then.

> Also, what about moving (some of) the concurrency library into the
> standard library?

I'm not opposed to doing that in principle - but I'd like to see a little
more detail first.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list