Question

BEGIN EDIT

The “right” way to do this (pre-4.5) is to use the SynchronizationContext as outlined here: http://msdn.microsoft.com/en-us/magazine/gg598924.aspx

I believe that in 4.5 SynchronizationContext is automatically handled for you with the async/await keywords, but haven’t done enough work to confirm.

In 4.0, you may want to utilize “TaskScheduler.FromCurrentSynchronizationContext” to capture the current thread’s context (in my case, this will include HttpContext, but various parts of the BCL provide similar constructs).

END EDIT

The primary question is:

Is the following a “safe” mechanism for sharing “context” with a task?

Without going into too much detail, in my use case, it’s not possible to push the context down into the action directly.

public static class ContextCaller{
    [ThreadStatic]
    public static object SharedState;

    public static Task InvokeWithContext(this Action theAction){
        //We're still running in the "outer" context, 
        //so we can collect a variable and store it in the thread-static
        //field by closing it into the task.
        var context = new object();

        var t = new Task(()=>{
            try{
                //close in the context
                SharedState = context;
                theAction();
            }
            finally{
                //teardown the shared state.
                SharedState = null;
            }
        });
        t.Start();
        return t;
    }
}

And now the client code:

//client code:
Action doWork = ()=>{
    var state = ContextCaller.SharedState;
    //do work on state, potentially throwing an exception in the process.
};

//cause the task to be invoked with some data available only on this thread.
doWork.InvokeWithContext();

Based on my understanding of the relationship between a task an a thread, the above should be safe, because:

1. One task will run on exactly one thread (with the assumption that the action does not spawn additional tasks/threads).
2. The ThreadStatic field is set
   before execution of “theAction()”, and “finally” guarantees this field is
   reset following the call to “theAction()”, regardless of outcome.

Aside from explicitly closing in the parameters to “theAction”, are there other, better, patterns for defining context on a Task?

Answer 1

I don’t see any technical reason why your code shouldn’t work fine.

But I also think doing this is a bad practice and I would use something like this only if there really isn’t any other way. And I think that adding another overload of your method that takes Action<object> (or even better, using a strongly-typed parameter) shouldn’t be a significant change.