Re: dynamic Bindings; thread-state

[mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]

Per Bothner <bothner@cygnus.com> wrote:
> My preference is thread-safe version of "fluid-let",

I'd rather separate the issues of thread-specific variables and fluid
("temporary") assignment to a variable, as both may be quite useful
independent of each other. For thread-specific variables, I'd think of
something like the following:

(define-per-thread VAR VALUE [PROC])

This defines the identifier VAR to denote a different storage location
in each thread.

VALUE is an expression, which is evaluated just like the expression in
an ordinary definition, and the result is remembered.

If PROC is omitted, it is equivalent to the meaning of (LAMBDA (I C) I)
in standard Scheme.

PROC is an expression, which is evaluated just like the expression in
an ordinary definition, and the result is remembered. It is an error
if the result isn't a procedure accepting two arguments and returning
one value.

The storage denoted by VAR in some thread is initialized with the result
of applying the remembered procedure to two arguments, the first of which
is always the first remembered value from the definition.

If the thread for which this initialization happens did already exist
when the definition of VAR took effect, the second argument will be the
same as the first one. In threads which are created later, the second
argument will be the value of VAR in that thread which created the new
thread, in cases where this does make any sense (e.g. if an implementation
defines implicit thread-creation in response to interrupts, it may not be
sensible to assume any relation to the interrupted thread; on the other
hand, explicit thread creation should take the creating thread into account),
otherwise it is also the same as the first argument. For the thread which
caused the definition of the per-thread variable to take effect (e.g. some
"initial" thread of the running Scheme program), the second argument is
always the same as the first one.

(This is necessarily somewhat ambiguous, since Scheme doesn't tell exactly
how/when storage denoted by top-level bindings comes into existence; e.g.
some implementation may allocate all such storage for some known program
at once, whereas others might perform sequential loading and allocation in
a way which could even be observed by a Scheme program, or mixtures of all
this. Programmers should be encouraged not to assume some particular way
of implementing this, or if they absolutely have to, know that they're
depending on the way some particular implementation happens to do it at
the time they're finding out about that particular implementation.)


In addition to this facility, and completely orthogonal, there should be a
FLUID-LET form which is essentially thread-unaware, and is (conceptually)
implemented in the now well-known way using DYNAMIC-WIND. If you use it from
several threads on the same non-per-thread variable without synchronization,
you lose, just as with any other form of assignment.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>