Re: thread local variables

[Russ McManus <russell.mcmanus@gs.com>]

Per Bothner <bothner@cygnus.com> writes:

> > I've been reading up on MzScheme's handling of thread local variables,
> > and they have a very neat system.
> 
> One problem is that this is inconsistent with the getter/setter
> paradigm we argued over a while ago.  Rather than:
> 	(current-output-port)
> 	(current-output-port P);  MzScheme - set (current-output-port) to P
> the plan is to do:
> 	(current-output-port)
> 	(set! (current-output-port) P)

Yes, that will be a problem.  But that is a syntax issue; I am more
interested in the semantics of parameters, in particular what happens
to thread local bindings when a new thread is spawned.

> My preferred solution for thread-local variables is a thread-safe
> version of fluid-let:
> 
> Syntax: fluid-let ((VARIABLE INIT) ...) BODY ... 
>      Evaluate the INIT expressions. Then modify the dynamic bindings for
>      the VARIABLES to the values of the INIT expressions, and evaluate
>      the BODY expressions. Return the result of the last expression in BODY.
>      Before returning, restore the original bindings. The temporary bindings
>      are only visible in the current thread, and its descendent threads.

Thread safe fluid-let is a good tool, I use it now.  But it fails to
address some of the issues you run into when working with multiple
threads.

For instance, when you spawn a new thread, which of the original
threads' bindings should be shared with the new thread?  One can
imagine for instance that the current output port could be shared
between the two threads.  It's not hard to imagine other uses:
let's say you have a cl-style parameter *print-circle*, one might
want to have this shared across threads, and have changes to it
automatically protected with a mutex.

The MzScheme system explicitly addresses these issues by defining two
new primitives: a parameter and a parameterization, which is a thread
local collection of parameters.  When spawning a new thread the user
can specify which parameters in the current thread's parameterization
should be copied into the new thread, and which should be shared with
the new thread.

Having an abstraction like this is very powerful, and I expect that it
would allow other important features to be implemented easily and
cleanly.

-russ



--
The optimist thinks this is the best of all possible worlds. The
pessimist fears it is true.	
             -- Robert Oppenheimer