[m-rev.] for review: thread-local mutables

[Julien Fischer]

On Wed, 10 Jan 2007, Peter Wang wrote:

> On 2007-01-10, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>> Hi Peter,
>>
>> A question ...
>>
>> On Wed, 10 Jan 2007, Peter Wang wrote:
>>
>>> 	Add a `thread_local_mutables' field to MR_Spark and update the
>>> 	parallel
>>> 	conjunction implementation to take into account thread-locals.
>>> 	Note that setting the value of a thread-local mutable inside a
>>> 	parallel
>>> 	conjunction is not supported.
>>
>> Isn't it just a matter of ensuring that when you create a new context
>> as the result of a parallel conjunction that it points to the parent's
>> thread_local_mutable array rather than creating a copy of it?  i.e.
>> we should only make a copy of the array when the user explicitly requests
>> the creation of a separate thread via spawn/3 rather than as a result
>> of threads created as a result of parallel conjunctions.
>
> I think you're right.
>
> I was thinking, if a parallel conjunct could read from an array while
> another parallel conjunct was updating the same array, we'd need to
> protect the array with a mutex.

Yes, so associated with each array would also be a mutex.  Threads
created by spawn/3 would create a new mutex, just as they create a copy
of the array.  Threads created by parallel conjunction would inherit
the mutex as well as the array.

> But it's a rather contrived situation,
> as impure goals are not allowed in parallel conjuncts:
>
>    set_var("foo", !IO),
>    (
> 	set_var("bar", !IO)
>    &
> 	semipure get_var(Var)
>    )

Are unique arguments, like the io.states, allowed in parallel 
conjunctions anyway.

> Var could be "foo" or "bar" here, so nobody should be writing this code
> anyway :-)

That's what purity promises are for.  If we ever moved to the more
fine-grained purity system that has been discussed we could effectively
have something like:

 	:- pragma promise_im_not_doing_something_silly_with_threads.

I guess it all boils down to what exactly `thread_local' means for
mutables?  Does it mean that the mutable is local to the Mercury thread
(i.e a thread explicitly created by a call to spawn/3) or does it mean
that is local to each pthread?  In the former case any further
"implementation" threads (i.e pthreads) used to implement parallel conjunction
should be not have their own copies of the thread local mutables.

At least that's my take on the matter.


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