C# Core - Task.Wait(int Timeout) not awaiting as expected

Question

I'm trying to implement a timeout mechanism for WCF calls that don't support CancellationTokens or pre-defined timeouts. In order to do that, I created a small project and came up with this structure:

       var st = Stopwatch.StartNew();

       try
       {
           var responseTask = Task.Run(() =>
           {
               var task = new WaitingService.ServiceClient().GetDataAsync(60000);
               if (!task.Wait(1000))
               {
                   return null;
               }
               return task.Result;
           });
           await responseTask;
       }
       catch { }
       return Ok("Awaited for " + st.ElapsedMilliseconds + "ms. Supposed to be " + sleep);

When I run this code on my local machine sequentially (1 call at a time) the output is very VERY close to 1000, missing by around 10 to 50ms, which is 100% acceptable.
But if I run this on a concurrent manner, let's say 5 request at-a-time, it starts to slip, to 100ms... if I run this on 25 concurrent requests I start to see the slip in seconds and when I run above 35 the slip is superior to 10 seconds (at which point I increased the sleep to 60s because the service was returning before the framework could "notice" that it had timeout)

Can anyone tell me what's going on? why is this "slip" happening at such a degree? is there a more reliable implementation for what I'm trying to achieve?

Details:
The service is very simple:

public string GetData(int value)
{
    Console.WriteLine("Will sleep for " + value);
    Thread.Sleep(value);
    return string.Format("Slept for: {0}ms", value);
}

EDIT 1
I also tested this scenario:

       var st = Stopwatch.StartNew();
       CancellationTokenSource src = new CancellationTokenSource(1000);

       try
       {
           var responseTask = Task.Run(() =>
           {
               var task = new WaitingService.ServiceClient().GetDataAsync(sleep);
               if (!task.Wait(1000,src.Token))
               {
                   return null;
               }
               task.Wait(src.Token);
               return task.Result;
           });
           await responseTask;
       }
       catch { }
       return Ok("Awaited for " + st.ElapsedMilliseconds + "ms. Supposed to be " + sleep);

But I actually got worse results... the slip intensified...

EDIT 2:
the following implementation got FAR better results, with 50 concurrent request rarely exceeding 2 seconds!

var st = Stopwatch.StartNew();

try
{
    var responseTask = Task.Run(async () =>
    {
        var task = new WaitingService.ServiceClient().GetDataAsync(sleep);
        do
        {
            await Task.Delay(50);
        }while (task.Status == TaskStatus.Running || st.ElapsedMilliseconds < 1000);
        if (task.Status == TaskStatus.RanToCompletion)
        {
            return task.Result;
        }
        else { return null; }
    });
    await responseTask;
}
catch { }
return Ok("Awaited for " + st.ElapsedMilliseconds + "ms. Supposed to be " + sleep);

Answer 1

Say suppose you have 10 threads in your process, and the threads are scheduled in round robin fashion, where each thread is getting only 2ms of execution time. Suppose if all the 10 threads are launched at the 0th ms and 20ms of StopWatch has elapsed, each thread is getting only 4ms of execution time, the rest of 16 ms, each thread would be waiting for its turn to get executed. So if you are blocking a specific thread for a certain amount of ms with the specific timeout value, it doesn't mean that the thread execution would be completed in that specified time. The actual time taken by the thread to complete the execution, includes the time the thread has been waiting to acquire the next execution cycle.

So when you call task.Wait(1000) the thread will be blocked for 1000ms of its execution time, but not the stop watch elapsed time

Answer 2

As others have explained in comments, the original async code snippet was blocking with the the usage of Task.Wait and Task.Result. This can cause issues and shouldn't be done.

Using Task.Run was causing the increased execution time that you were seeing as the threadpool was becoming exhausted with the increasing number of sequential calls.

If you would like to run a Task with a timeout, without blocking, you could use the following method:

public static async Task<(bool hasValue, TResult value)> WithTimeout<TResult>(Task<TResult> task, int msTimeout)
{
    using var timeoutCts = new CancellationTokenSource();

    var timeoutTask = Task.Delay(msTimeout, timeoutCts.Token);
    var completedTask = await Task.WhenAny(task, timeoutTask);

    if (completedTask == task)
    {
        timeoutCts.Cancel(); //Cancel timeoutTask
        return (true, await task); //Get result or propagate exception
    }

    //completedTask was our timeoutTask
    return (false, default);
}

This method combines Task.WhenAny and Task.Delay to run a timeout task alongside the task argument passed in. If the task passed in completes before the timeout, the result will be returned. However if the timeout completes first, a (hasValue: false, value: default) is returned.

Usage with your example:

var task = new WaitingService.ServiceClient().GetDataAsync(sleep);
var result = await WithTimeout(task, 1000);

if (result.hasValue)
{
   //Do something with result.value;
}

It's important to note that as your task does not support cancellation, it will continue to run. Unless it's handled elsewhere, it could throw an exception that is not caught.

Because we're awaiting the tasks through the non-blocking Task.WhenAny, you shouldn't be exhausting the threadpool as you were seeing in the original example.

In your last example, there is potential for an unnecessary extra 0-50ms of delay before continuing with a result. This method will return immediately when a task completes within the timeout period.