Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

339
Vistas
Is calling Task.Wait() immediately after an asynchronous operation equivalent to running the same operation synchronously?

In other words, is

var task = SomeLongRunningOperationAsync();
task.Wait();

functionally identical to

SomeLongRunningOperation();

Stated another way, is

var task = SomeOtherLongRunningOperationAsync();
var result = task.Result;

functionally identical to

var result = SomeOtherLongRunningOperation();

According to Task.Wait and Inlining, if the Task being Wait’d on has already started execution, Wait has to block. However, if it hasn’t started executing, Wait may be able to pull the target task out of the scheduler to which it was queued and execute it inline on the current thread.

Are those two cases merely a matter of deciding which thread the Task is going to run on, and if you're waiting on the result anyway, does it matter?

Is there any benefit to using the asynchronous form over the synchronous form, if nothing executes between the asynchronous call and the Wait()?

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

Here are some differences:

  1. The computation might run on a different thread. It might run on the same thread if this task is CPU-based and can be inlined. This is non-deterministic.
  2. If no inlining happens one more thread will be in use during the computation. This usually costs 1MB of stack memory.
  3. Exceptions will be wrapped in AggregateException. The exception stack will be different.
  4. The task version might deadlock if the computation posts to the current synchronization context.
  5. If the thread-pool is maxed out this might deadlock if for the task to complete another task must be scheduled.
  6. Thread-local state, such as HttpContext.Current (which is not actually thread-local but almost), might be different.
  7. A thread abort of the main thread will not reach the task body (except in case of inlining). I'm not sure whether the wait itself will be aborted or not.
  8. Creating a Task induces a memory barrier which can have a synchronizing effect.

Does this matter? Decide for yourself by this list.

Are there benefits to doing this? I can't think of any. If your computation uses async IO the wait will negate the benefits that the async IO brings. The one exception would be fan-out IO, e.g. issuing 10 HTTP requests in parallel and waiting for them. That way you have 10 operations at the cost of one thread.

Note, that Wait and Result are equivalent in all these regards.

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda