[m-dev.] Globals and concurrency

[Julien Fischer]

On Tue, 1 Aug 2006, Peter Wang wrote:

> On 2006-08-01, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>> 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)?
>
> Yes.

Actually, now I've had more of a think about it, that's not quite the
problem.  Since io.{get, set}_globals are marked with `not_thread_safe'
any thread executing one of them has to acquire the global mutex, so
only one of them can be executed at time.  The problem, in the above
example is that while one thread is executing foo(Globals0, Globals),
another may come along and call set, get globals and stuff everything
up.

What is needed is something to tell the compiler that the above three
calls are a critical region, like synchronized blocks in Java.

Some thoughts:

- the current implementation of mutables with `thread_safe' is quite
   unsafe.

- we could a new attribute `update' to the mutable declarations.  This
   would cause the compiler to generate an update predicate that would
   allow you to update the value of a mutable without interference from
   other threads.

   e.g.

 	:- mutable(varname, vartype, intial_value, varinst, [...]).

   becomes something like:

 	:- pred update_varname((func(vartype) = vartype), io, io).
 	:- mode update_varname((func(in) = out is det), di, uo) is det.

 	update_varname(F, !IO) :-
 		<acquire lock on varname>,
 		io.get_varname(V0, !IO),
 		V = F(V0),
 		io.set_varname(V, !IO),
 		<release lock on varname>.

         - for that to work each mutable would need an associated mutex.
 	- since F doesn't take the I/O state that prevents F itself
 	  trying to alter the value of the mutable (unless you use the
           impure interface.)

- at the "lots of work" end of the spectrum these things could be
   built into the language, synchronized scopes or something (to borrow
   the Java terminology for them.

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

And it's the mutable version of the problem that needs to be solved - 
at worst fixing io.{get,set}_globals will just involve implementing
that the mutable solution for them by hand.

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
--------------------------------------------------------------------------