Context

Context

Contexts are a way to structure the state and Configuration of an Evaluator. A Context exists on one and only one individual Evaluator. Each Evaluator has at least one Context, which we refer to as the root Context. This root context is special, as it is required on all Evaluators and because closing it is synonymous to releasing the Evaluator. In many simple REEF programs, this is the only Context used and it is therefore convenient to think of it as synonymous to "the Evaluator": The Driver can submit Tasks to it, is notifified when they are done and can close the root context when it wants to dispose of the Evaluator.

Contexts are formed by calls to submitContext() to the event types that allow this (AllocatedEvaluator and ActiveContext) Contexts are the main way for an Evaluator to be exposed and accessed. For instance, Tasks are submitted to an ActiveContext which represents the top Context on the Evaluator.

Contexts form a stack

Beyond this, a Driver can submit a Context to the root, or in fact any, Context, as long as the resulting structure is that of a stack: The root Context forms the bottom of the stack, the top-most Context is called active, hence the ActiveContext event. The two can be one and the same, and often are: The root Context is the subject of the first ActiveContext event on an Evaluator.

Nomenclature: When Context B is submitted to an already existing Context A, we say that Context A is the parent Context of Context B. Also, Context B is the child of Context A.

It is only the ActiveContext that allows the submission of Tasks or child Contexts. Hence, one can think of the whole Evaluator structure as that of a stack: the root Context at the bottom, layers of Contexts in the middle and either the current ActiveContext or the current Task at the top.

Objects and Configuration: What's in a Context?

It is convenient to think of a Context as a Configuration that gets merged with the Configuration supplied for Tasks and child Contexts. While not entirely true (see below), this view allows us to show just why Contexts are a convenient construct.

It is often the case that subsequent tasks that get executed on an Evaluator want access to the same Configuration variables and / or the same objects. Consider a simple LinkedList bound to a named parameter. If that linked list is part of the subsequent Task Configurations submited, each Task will get its very own LinkedList. If the named parameter is bound in the Context Configuration, all Tasks subsequently submitted to the Context will get the very same LinkedList instance.

Contexts are (Tang) Injectors

This mechanism is implemented by using Tang's Injectors. On the Evaluator, a Task is launched by first forking the Context's Injector with the Task Configuration and then requesting an instance of the Task interface from that forked Injector. By this mechanism and the fact that objects are singletons with respect to an Injector in Tang, object sharing can be implemented. All objects already instantiated on the Context Injector will also be referenced by the Task Injector. Hence, the LinkedList in the example above would be shared amongst subsequent Task Injectors in the construction of the Task instance.