Persist thread's context across async calls

Question

I am trying to disentangle my logs by grouping my log messages together. Ideally, I'd append to each message some identifier indicating that it is part of a group of commands achieving some piece of work.

If this were a single threaded application, the thread's ID would be a candidate. However, this solution makes heavy use of async Tasks, which precludes its use. Is it possible to get something like the following to work, where every execution of Main() would always print out the same thread ID?

static async void Main()
{
    var t = Task.Run(async () => await MyAsyncMethod());
    await t;
}

private static async Task MyAsyncMethod()
{
  Debug.WriteLine("Log message: {0}", Thread.CurrentThread.ManagedThreadId);

  await Task.Delay(1000);

  Debug.WriteLine("Log message: {0}", Thread.CurrentThread.ManagedThreadId);

  await Task.Delay(1000);

  Debug.WriteLine("Log message: {0}", Thread.CurrentThread.ManagedThreadId);
}

Generate a id in beginning of the method and use it all over? Or write some id related to what you async method is processing. For example, if it process some customer related work, it will be customer id. — Sriram Sakthivel, May 04 '15 at 19:32
@SriramSakthivel Good suggestions, but I'm trying to get away without refactoring a solution that is quite large. And ideally the property I group by wouldn't be related to the business, as I can have multiple worker roles processing the same entity at the same time, so log messages are being interleaved, which is causing me confusion. — Mister Epic, May 04 '15 at 19:54
Related problem: http://stackoverflow.com/questions/15898369/debugging-async-await-call-stack — Moby Disk, May 04 '15 at 20:00
Two notes on the code: 1) [Async void should be avoided unless this is a top-level event handler](https://msdn.microsoft.com/en-us/magazine/jj991977.aspx) and 2) if by `Main` you intend this to be the entry point of a console app, you'll need [a message pump](http://blogs.msdn.com/b/pfxteam/archive/2012/01/20/10259049.aspx) to do it properly. — Matt Johnson-Pint, May 04 '15 at 21:02

Stephen Cleary · Accepted Answer · 2015-05-05T21:32:58.803

The best approach IMO is what @SriramSakthivel suggested: just generate an id and pass it around. If you have a "message" type, you could just add it to that type.

However, if this would cause too much of a code change, then you can pass it implicitly. I have a blog post with the gory details; the general idea is that you store the data as part of the logical call context:

public static class MyContext
{
  private static readonly string name = Guid.NewGuid().ToString("N");

  private sealed class Wrapper : MarshalByRefObject
  {
    public Guid Value { get; set; }
  }

  public static Guid CurrentContext
  {
    get
    {
      var ret = CallContext.LogicalGetData(name) as Wrapper;
      return ret == null ? Guid.Empty : ret.Value;
    }

    set
    {
      CallContext.LogicalSetData(name, new Wrapper { Value = value });
    }
  }
}

Then you can use it from your code as such:

private static async Task MyAsyncMethod()
{
  MyContext.CurrentContext = Guid.NewGuid();

  Debug.WriteLine("Log message: {0}", MyContext.CurrentContext);

  await Task.Delay(1000);

  Debug.WriteLine("Log message: {0}", MyContext.CurrentContext);

  await Task.Delay(1000);

  Debug.WriteLine("Log message: {0}", MyContext.CurrentContext);
}

Note that this approach makes two crucial assumptions:

Your code runs on .NET 4.5 or newer.
The data being stored is immutable (which is true in this case, since Guid is immutable).

It looks like something like this will be builtin in .NET 4.6.

Looks great! `CurrentContext` should be public though, no? – Mister Epic May 05 '15 at 14:24 — Mister Epic, May 05 '15 at 14:24

Persist thread's context across async calls

1 Answers1