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.
> 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). 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? Marc