Ulrich Hobelmann <email@example.com> wrote:
| Ron Garret wrote:
| > That fails if you have multiple threads. This was discussed to death
| > last January. Google for the thread called "Smug Scheme weenies."
| If you have multiple threads referencing the same special variable, yes.
| I'd consider that very bad style though and make all special variables
| per-thread by default...
That doesn't work, either! How could you possibly share global data
if *all* special variables were per-thread?!? Remember, Common Lisp
has nothing *but* special variables as globals.
No, what most Common Lisp implementations which provide threads
actually do is "the right thing":
1. If a thread has not LET-bound (or LAMBDA-bound) a global/special
variable, it sees the same binding as other threads which have not
bound it. A SETF by any such thread is seen by all such threads.
2. If a thread LET-binds (or LAMBDA-binds) a special variable, then
that binding is thread-local for the dynamic duration of that
binding. A SETF or rebinding of that special variable while so
bound will be seen only by that thread. [Other special variables
which have not been LET/LAMBDA-bound by that thread will behave
as in #1.]
Conversely, such a thread will not see any SETFs to a variable
it has bound by non-binding threads (as in #1) until it exits the
LET/LAMBDA- binding contour, at which point it will see whatever
the current "global" value happens to be.
Said more succinctly: If you want a special variable to be thread-
local, bind it. If you want it to be global, SETF it.
To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
and probably others as well. [LW?]
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607