Threads and static initialization.

[Jonathan M Davis]

On Friday 17 December 2010 13:47:05 wrzosk wrote:
> I believe that when new thread is being created, all static data is
> initialized inside new thread. What worries me is the fact, that many
> 'mini' threads will initialize all static data inside application. This
> may be somewhat time consuming.
> Maybe there should be a possibility to define 'Pure' thread that doesnt
> touch any static data, and in turn it could leave static constructors
> untouched.
> 
> What do you think

That seems like it would be _really_ hard to do - probably impossible. The 
compiler would have to know which functions, types, and variables a thread 
accessed. I don't believe that compiler really knows anything about threads. It 
doesn't know which thread calls a particular function or accesses a particular 
variable. It knows about thread-local storage vs shared storage, and the type 
system restricts conversions between the two, but to do what you're suggesting, 
you'd have to have the compiler know which thread is calling which function and 
disallowing - at compile time - certain threads from calling certain functions. 
As it is, any thread can call anything and the compiler makes no attempt at 
tracking any of that. It just has restrictions with regards to thread-local and 
shared.

So, while it certainly seems like a good idea, I don't see how it would really 
be possible. It might be possible to make it so that a thread could be created 
which did not initialize any module or static variables (be they at class, 
struct, or function scope), but I don't see how the compiler could enforce that 
none of those variables were used. It would have to be up to the programmer to 
only call pure functions.

What _might_ be possible would be if you had a way of starting a thread which 
took a function (or overrode one) and that function _had_ to be strongly pure. 
Then it could skip running static constructors, because it would be impossible 
for any static variables to be accessed. However, the only way that you'd then 
get access to anything that thread did was from the return value of the function 
that started it, which not raises the issue of how you'd get the return value 
with the asynchronous nature of threads, but it would restrict the usage of such 
threads to the point that they'd be practically useless.

I think that you raise a valid concern, but I don't think that that's the way to 
handle it. Restricting static constructors and global or static variables in 
practice will help, and using immutable more will help. But if we want a means 
of making threads more lightweight, we probably need to look at a different way 
of doing it than you're suggesting.

This does make me wonder about static constructors and immutable though. It's 
currently possible to assign to both immutable and mutable module-scope 
variables in a static constructor. Such static constructors _must_ run for every 
thread or the thread-local portions are going to be wrong, but you _can't_ run 
them for immutable variables or you aren't sharing them between threads (or 
you're reassigning them each time that at new thread is created - I think that 
there's currently a bug on that). Perhaps static constructors which assign to 
immutable variables should have to be immutable, and mutable variables would 
have to be assigned in non-immutable static constructors. Then the immutable 
static constructors only get run once with the main thread, whereas the non-
static ones get run for every thread.

- Jonathan M Davis