So, TLS solves the data issue with threading. I just thought,
with out much thinking, what about having thread local functions?
Doesn't make sense? Let me explain.
Functions generally are not thread safe because of reentry,
right? The same data is used by the function for each thread
calling it and sense threads could effectively call a function
while the same function is being executed by another thread, the
data is correct.
To solve this, why not "parameterize" functions based on threads.
Essentially:
void funcThread1(...) { ... }
void funcThread2(...) { exactly the same code as above }
funcThread1 is only ever called on thread 1 and funcThread2 is
only ever called on thread 2. There is no issues of threading as
these functions are essentially thread local.
We can also combine them into one function:
// set stack based on threadidx before call. (for n threads there
are n stacks for this function)
void funcThread(...) { ... }
in this case, the compiler can simply set the stack based on the
thread id.
Should this not solve issues with functions in threading in a
similar way that TLS works? (it's just making the stack thread
local and functions are just code and data, the data part being
the issue)
While suck code might not work in all scenarios(such as in
general parallelization) it would make code for threading much
simpler to write(no locks) in many cases. As far as I can see,
the only real issue is that the stack is not thread local for
functions and hence acts as a global variable for functions,
which is the problem?
Is this possible?
