[M3devel] Thread local storage?
Rodney M. Bates
rodney_bates at lcwb.coop
Thu Apr 14 17:45:06 CEST 2011
I have never understood what "thread local storage" is all about, in particular,
what need it addresses.
All local variables and parameters are already private to a thread, as consequence
of semantics going back as far as Algol-60. They are allocated space when and
only when a call is executed. That can't happen until there is a thread to
execute the call and it has to have its own private stack where the space is
allocated, or it wouldn't work as a thread, (OK leaving out languages like
very old Fortrans that don't support recursion either.)
That leaves global variables. At least some of these have to be shared by all
the threads of a process, or the threads could have no shared memory interaction,
and thus no function that would not be served by just separate processes running
separate main programs.
If you need variables that are private to a thread but in some sense global,
just put them in the Thread.Closure. They would hardly make sense as declared
lexically global variables anyway, since, except for the initial thread provided
by the OS/RTS, their lifetime does not cover the entire execution of the main
program.
So what are they really, and what are they for? And do we even have or use them in
Modula-3?
It is looking to me like some sort of accommodation for them in cm3cg may be what has
undermined m3gdb in the CVS head.
Rodney Bates
More information about the M3devel
mailing list