velocidades - ¿Hay un mejor patrón de espera para c#?

velocidades patrones de espera oaci

Question

Me he encontrado codificando este tipo de cosas un par de veces.

for (int i = 0; i < 10; i++)
{
   if (Thing.WaitingFor())
   {
      break;
   }
   Thread.Sleep(sleep_time);
}
if(!Thing.WaitingFor())
{
   throw new ItDidntHappenException();
}

Simplemente parece un código incorrecto, ¿hay una mejor manera de hacerlo / es un síntoma de un mal diseño?

Answer 1

Aquí es cómo puedes hacerlo con System.Threading.Tasks :

Task t = Task.Factory.StartNew(
    () =>
    {
        Thread.Sleep(1000);
    });
if (t.Wait(500))
{
    Console.WriteLine("Success.");
}
else
{
    Console.WriteLine("Timeout.");
}

Pero si no puede usar Tareas por algún motivo (como un requisito de .Net 2.0), puede usar el ManualResetEvent como se menciona en la respuesta de JaredPar o usar algo como esto:

public class RunHelper
{
    private readonly object _gate = new object();
    private bool _finished;
    public RunHelper(Action action)
    {
        ThreadPool.QueueUserWorkItem(
            s =>
            {
                action();
                lock (_gate)
                {
                    _finished = true;
                    Monitor.Pulse(_gate);
                }
            });
    }

    public bool Wait(int milliseconds)
    {
        lock (_gate)
        {
            if (_finished)
            {
                return true;
            }

            return Monitor.Wait(_gate, milliseconds);
        }
    }
}

Con el enfoque Esperar / Pulsar, no crea eventos explícitamente, por lo que no necesita preocuparse por eliminarlos.

Ejemplo de uso:

var rh = new RunHelper(
    () =>
    {
        Thread.Sleep(1000);
    });
if (rh.Wait(500))
{
    Console.WriteLine("Success.");
}
else
{
    Console.WriteLine("Timeout.");
}

Answer 2

Creo que deberías usar AutoResetEvents. Funcionan muy bien cuando esperas que otro hilo termine su tarea

Ejemplo:

AutoResetEvent hasItem;
AutoResetEvent doneWithItem;
int jobitem;

public void ThreadOne()
{
 int i;
 while(true)
  {
  //SomeLongJob
  i++;
  jobitem = i;
  hasItem.Set();
  doneWithItem.WaitOne();
  }
}

public void ThreadTwo()
{
 while(true)
 {
  hasItem.WaitOne();
  ProcessItem(jobitem);
  doneWithItem.Set();

 }
}

Answer 3

Por lo general, desaconsejo tirar excepciones.

// Inside a method...
checks=0;
while(!Thing.WaitingFor() && ++checks<10) {
    Thread.Sleep(sleep_time);
}
return checks<10; //False = We didn''t find it, true = we did

Answer 4

Si es posible, haga que el procesamiento asíncrono se ajuste a una Task<T> . Esto proporciona lo mejor de todos los mundos:

• Puede responder a la finalización de una manera similar a un evento mediante el uso de continuación de tareas .
• Puede esperar utilizando el identificador waitable de la finalización porque Task<T> implementa IAsyncResult .
• Las tareas se pueden componer fácilmente utilizando Async CTP ; también juegan bien con Rx .
• Las tareas tienen un sistema de manejo de excepciones integrado muy limpio (en particular, conservan correctamente el seguimiento de la pila).

Si necesita utilizar un tiempo de espera, Rx o Async CTP pueden proporcionar eso.

Answer 5

Un bucle no es una manera TERRIBLE de esperar algo, si su programa no tiene nada más que hacer mientras espera (por ejemplo, mientras se conecta a un DB). Sin embargo, veo algunos problemas con los suyos.

    //It''s not apparent why you wait exactly 10 times for this thing to happen
    for (int i = 0; i < 10; i++)
    {
        //A method, to me, indicates significant code behind the scenes.
        //Could this be a property instead, or maybe a shared reference?
        if (Thing.WaitingFor()) 
        {
            break;
        }
        //Sleeping wastes time; the operation could finish halfway through your sleep. 
        //Unless you need the program to pause for exactly a certain time, consider
        //Thread.Yield().
        //Also, adjusting the timeout requires considering how many times you''ll loop.
        Thread.Sleep(sleep_time);
    }
    if(!Thing.WaitingFor())
    {
        throw new ItDidntHappenException();
    }

En resumen, el código anterior se parece más a un "ciclo de reintento", que ha sido bastardeado para funcionar más como un tiempo de espera. Así es como estructuraría un ciclo de tiempo de espera:

var complete = false;
var startTime = DateTime.Now;
var timeout = new TimeSpan(0,0,30); //a thirty-second timeout.

//We''ll loop as many times as we have to; how we exit this loop is dependent only
//on whether it finished within 30 seconds or not.
while(!complete && DateTime.Now < startTime.Add(timeout))
{
   //A property indicating status; properties should be simpler in function than methods.
   //this one could even be a field.
   if(Thing.WereWaitingOnIsComplete)
   {
      complete = true;
      break;
   }

   //Signals the OS to suspend this thread and run any others that require CPU time.
   //the OS controls when we return, which will likely be far sooner than your Sleep().
   Thread.Yield();
}
//Reduce dependence on Thing using our local.
if(!complete) throw new TimeoutException();

Answer 6

Una forma mucho mejor de implementar este patrón es hacer que su objeto Thing exponga un evento en el que el consumidor puede esperar. Por ejemplo, un ManualResetEvent o AutoResetEvent . Esto simplifica enormemente su código de consumidor para ser el siguiente

if (!Thing.ManualResetEvent.WaitOne(sleep_time)) {
  throw new ItDidntHappen();
}

// It happened

El código en el lado de la Thing tampoco es realmente más complejo.

public sealed class Thing {
  public readonly ManualResetEvent ManualResetEvent = new ManualResetEvent(false);

  private void TheAction() {
    ...
    // Done.  Signal the listeners
    ManualResetEvent.Set();
  }
}

Answer 7

Una llamada a Thread.Sleep siempre es una espera activa que debe evitarse.
Una alternativa sería usar un temporizador. Para un uso más fácil, puede encapsular eso en una clase.

Answer 8

Usa eventos

Haga que lo que está esperando genere un evento cuando finalice (o no termine dentro del tiempo asignado) y luego maneje el evento en su aplicación principal.

De esa forma no tienes ningún bucle de Suspensión.

Answer 9

WaitHandle un vistazo a la clase WaitHandle . Específicamente, la clase ManualResetEvent que espera hasta que se establece el objeto. También puede especificar valores de tiempo de espera para él y verificar si se estableció después.

// Member variable
ManualResetEvent manual = new ManualResetEvent(false); // Not set

// Where you want to wait.
manual.WaitOne(); // Wait for manual.Set() to be called to continue here
if(!manual.WaitOne(0)) // Check if set
{
   throw new ItDidntHappenException();
}