patternMinor
What techniques could be used to support thread-local contexts and resources in a language?
Viewed 0 times
localwhatusedcouldlanguagethreadandresourcescontextstechniques
Problem
I am interested in the subject of thread-local contexts, which is a feature that I use quite often in solutions, but seems to lack first-class support in any languages I have used.
Quite often in programming - especially if you are implementing a solution that repeatedly processes similar inputs - it is useful to have access to a thread-local context.
I am sure many are familiar with this problem: the typical case I am taking about is where you have a processing engine taking input messages/requests (e.g., an MDB or a Servlet in Java) that is instantiated individually for several threads, and this engine repeatedly processes the messages using some resources or context that it owns. These resources could be expensive to recreate (and therefore we would like to reuse them), or alternatively, they need to be retained across requests in the thread, but do not need global scope in the application.
In this case, code needs to be able to access that context in an efficient way, but due to the stack+heap-based approach of most languages this is difficult. The current solutions are to either use something like
It occurs to me that such a thread context is a bit like a second stack. A stack has thread scope and can be efficiently accessed by the thread.
Possibly solutions to implement this in-language might be to maintain the context at the base of the stack; however, this would have to be a fixed size. For a variable sized context, a reference could be stored at the base, but with some loss of efficiency for minimalist requirements. Other options might be possible if the hardware supported multiple stacks per thread.
As a trivial example of what I mean to illustrate the performance impact of existing solutions would be to imagine each "engine" receives a message a
Quite often in programming - especially if you are implementing a solution that repeatedly processes similar inputs - it is useful to have access to a thread-local context.
I am sure many are familiar with this problem: the typical case I am taking about is where you have a processing engine taking input messages/requests (e.g., an MDB or a Servlet in Java) that is instantiated individually for several threads, and this engine repeatedly processes the messages using some resources or context that it owns. These resources could be expensive to recreate (and therefore we would like to reuse them), or alternatively, they need to be retained across requests in the thread, but do not need global scope in the application.
In this case, code needs to be able to access that context in an efficient way, but due to the stack+heap-based approach of most languages this is difficult. The current solutions are to either use something like
ThreadLocal in Java or to pass a pointer to the context down the stack, both which are not really language constructs, and both of which impose some overhead (and in the second case have practical issues).It occurs to me that such a thread context is a bit like a second stack. A stack has thread scope and can be efficiently accessed by the thread.
Possibly solutions to implement this in-language might be to maintain the context at the base of the stack; however, this would have to be a fixed size. For a variable sized context, a reference could be stored at the base, but with some loss of efficiency for minimalist requirements. Other options might be possible if the hardware supported multiple stacks per thread.
As a trivial example of what I mean to illustrate the performance impact of existing solutions would be to imagine each "engine" receives a message a
Solution
One example of a language system built from bottom up to support this kind of situation is Erlang. It is well worth looking into.
It is built around the concept that you create a lot of tasks. The tasks never share variables and only communicates via messages. The task has a "thread-local" context which is maintained using a very specific construct of tail-recursion. It is not uncommon to have thousands or even millions of task in a Erlang system.
Erlang comes with a set of constructs and tools known as OTP which helps in handling a number of common situation in soft real time systems. I especially like how it allows you to update the programs in a running system on the fly.
It is built around the concept that you create a lot of tasks. The tasks never share variables and only communicates via messages. The task has a "thread-local" context which is maintained using a very specific construct of tail-recursion. It is not uncommon to have thousands or even millions of task in a Erlang system.
Erlang comes with a set of constructs and tools known as OTP which helps in handling a number of common situation in soft real time systems. I especially like how it allows you to update the programs in a running system on the fly.
Context
StackExchange Computer Science Q#56114, answer score: 2
Revisions (0)
No revisions yet.