Task.Run randomly fails when using ExecutionContext.SuppressFlow

[davhdavh]

Description

TaskScheduler.TryRunInline does not take into account if ExecutionContext.SuppressFlow is in effect.

Reproduction Steps

Helper.Set("1");

for (int i = 0; i < 10000; i++)
{
   await Task.Run(Execute);
}

static void Execute()
{
   var suppressFlow = ExecutionContext.SuppressFlow();
   var startNew = Task.Factory.StartNew(() =>
      {
         if (Helper.Get() is { } v) throw new(v);
      }
   );
   startNew.GetAwaiter().GetResult();
   suppressFlow.Undo();
}

static class Helper
{
   private static readonly AsyncLocal<string?> _asyncLocal = new();

   public static string? Get() => _asyncLocal.Value;
   public static void Set(string? s) => _asyncLocal.Value = s;
}

Expected behavior

No exceptions

Actual behavior

Randomly throws depending on TaskSchedulers mood.

Regression?

No, but it is more broken in .NET Framework

Known Workarounds

Setting TaskCreationOptions.PreferFairness or TaskCreationOptions.LongRunning prevents the problem, but requires Developer knowledge that any task is executed in suppression.

Configuration

tried on .NET Framework 4.8 & .NET 6/7

Other information

.NET Framework 4.8 will almost certainly fail on first run.
.NET 6/7 will fail within 10-20 runs.

Tagging subscribers to this area: @dotnet/area-system-threading-tasks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

TaskScheduler.TryRunInline does not take into account if ExecutionContext.SuppressFlow is in effect.

Reproduction Steps

Helper.Set("1");

for (int i = 0; i < 10000; i++)
{
   await Task.Run(Execute);
}

static void Execute()
{
   var suppressFlow = ExecutionContext.SuppressFlow();
   var startNew = Task.Factory.StartNew(() =>
      {
         if (Helper.Get() is { } v) throw new(v);
      }
   );
   startNew.GetAwaiter().GetResult();
   suppressFlow.Undo();
}

static class Helper
{
   private static readonly AsyncLocal<string?> _asyncLocal = new();

   public static string? Get() => _asyncLocal.Value;
   public static void Set(string? s) => _asyncLocal.Value = s;
}

Expected behavior

No exceptions

Actual behavior

Randomly throws depending on TaskSchedulers mood.

Regression?

No, but it is more broken in .NET Framework

Known Workarounds

Setting TaskCreationOptions.PreferFairness or TaskCreationOptions.LongRunning prevents the problem, but requires Developer knowledge that any task is executed in suppression.

Configuration

tried on .NET Framework 4.8 & .NET 6/7

Other information

.NET Framework 4.8 will almost certainly fail on first run.
.NET 6/7 will fail within 10-20 runs.

Author:	davhdavh
Assignees:	-
Labels:	area-System.Threading.Tasks, untriaged
Milestone:	-

[stephentoub]

TaskScheduler.TryRunInline does not take into account if ExecutionContext.SuppressFlow is in effect.

Correct, this is by design. Or more specifically, TaskScheduler.Default's TryExecuteTaskInline doesn't pay any attention to whether ExecutionContext flow is suppressed. That was never the intent of EC flow suppression. The intent was as an optimization for the caller to say "don't bother capturing the current context and don't bother storing it, as the work doesn't care about what EC is present when it runs". There was never the intent of a guarantee that the current EC wouldn't be present during the execution of the task.

Known Workarounds

You can also use your own TaskScheduler that does whatever it wants in TryExecuteTaskInline, or you can avoid using .Wait/.GetAwaiter().GetResult/.Result to block waiting on a task.

[davhdavh]

The problem is that there seems to be no way to get this guarantee. As you have said it is be design that you can't depend on SupressFlow. (And thus any future change to Task/Thread/Threadpool may expand on this behaviour ) And ExecutionContext does not contain any methods to get a clean execution context and then use that in .Run. The flags only works with the default taskscheduler, any other taskscheduler is free to ignore it and it isnt even guaranteed because the semantics of tryexecuteinline only specifies that if it returns true it was executed inline there is no guarantee that it wont be on false. And again there is no guarantee either way that this would then respect supressflow. And it takes many many hours to figure out why your PLinq randomly fails just because you used AsyncLocal somewhere.

…

On Wed, Sep 28, 2022, 21:02 Stephen Toub ***@***.***> wrote: TaskScheduler.TryRunInline does not take into account if ExecutionContext.SuppressFlow is in effect. Correct, this is by design. Or more specifically, TaskScheduler.Default's TryExecuteTaskInline doesn't pay any attention to whether ExecutionContext flow is suppressed. That was never the intent of EC flow suppression. The intent was as an optimization for the caller to say "don't bother capturing the current context and don't bother storing it, as the work doesn't care about what EC is present when it runs". There was never the intent of a guarantee that the current EC wouldn't be present during the execution of the task. Known Workarounds You can also use your own TaskScheduler that does whatever it wants in TryExecuteTaskInline, or you can avoid using .Wait/.GetAwaiter().GetResult/.Result to block waiting on a task. — Reply to this email directly, view it on GitHub <#76297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJFIDJBWCVY5YKVTFO53ETWARFWDANCNFSM6AAAAAAQXS5N6U> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[stephentoub]

And ExecutionContext does not contain any methods to get a clean execution context and then use that in .Run.

It doesn't. But as the very first thing you do in your app's Main method, you can ExecutionContext.Capture and store that as your own singleton which you use with ExecutionContext.Run any time you want to get a clean slate. You can also use ThreadPool.UnsafeQueueUserWorkItem to be scheduled without flowing EC to a thread pool thread.

As noted, the described behavior is by design, so I'm going to close this issue accordingly. If your goal is actually to get new APIs added to achieve something in particular, please open API proposals for those.

Thanks!