Marc Feeley wrote:
>>At Mon, 30 Dec 2002 09:29:22 -0500, Marc Feeley wrote:
>>
>>>No "copy-on-write" is not a valid implementation.  The reason is that
>>>the "swapping" semantics requires the child thread to have an
>>>independent copy of the parent's thread.  So the child must get a
>>>snapshot of the parent's dynamic environment which will make the
>>>child's mutations invisible to the parent ***AND*** the parent's
>>>mutations invisible to the child.  The copy-on-write approach you
>>>suggest only makes the child's mutations invisible to the parent.
>>
>>Depends on what you mean by "copy on write". I'd say that MzScheme uses
>>"copy on write", and I mean that a copy is made whenever the parent or
>>child changes a parameter value. (I think that's consistent with
>>Felix's suggestion.)
>
>
> This works if at thread creation the dynamic environment is flagged as
> "to be copied on mutation" and both parent and child continue with a
> reference to this environment.  But I would say that this lazy copying
> can be quite expensive...  in fact it can be up to twice as expensive
> as taking a fresh (eager) copy of the parent's dynamic environment for
> the child thread, because both parent and child may end up copying the
> whole dynamic environment.  Having to copy the whole environment or
> some large fraction of it is likely in the swapping semantics because
> it handles "parameterize" by mutating parameter objects.  So my point
> that the "swapping" semantics makes thread-creation expensive remains
> (the cost may not be paid immediately, but it will slow down the
> execution of the program as a whole).

That still has to be shown. I claim that this slowdown will be
acceptable under "normal" cicumstances. Apart from artificial
scenarios I don't see too much trouble here.

>
> Aside from this I'm curious about the representation of the dynamic
> environment in PLT and Chicken.  Is the whole environment copied on
> the first mutation, only the parameter being mutated (which would
> require initializing one flag per parameter at a cost of
> O(nb. parameters)), or the parameters on the path to the parameter (in
> a balanced tree implementation)?  Only the balanced tree
> implementation appears to have a scalable performance (thread-creation
> is O(1) and lazy-copying cost is O(M log M) where M is the number of
> parameters that are mutated).  Is this what PLT and Chicken use?
>

Chicken copies the whole parameter-environment, which is a vector,
on the first mutation. Note that this "parameter" environment is
only a part of a thread's dynamic environment.

cheers,
felix