[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some comments

This page is part of the web mail archives of SRFI 39 from before July 7th, 2015. The new archives for SRFI 39 contain all messages, not just those from before July 7th, 2015.

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.