Wie kann ich warten, bis ein C# - Ereignis ausgelöst?

Ich habe eine Sender - Klasse, sendet eine Message auf eine IChannel:

public class MessageEventArgs : EventArgs {
  public Message Message { get; private set; }
  public MessageEventArgs(Message m) { Message = m; }
}

public interface IChannel {
  public event EventHandler<MessageEventArgs> MessageReceived;
  void Send(Message m);
}

public class Sender {
  public const int MaxWaitInMs = 5000;
  private IChannel _c = ...;

  public Message Send(Message m) {
    _c.Send(m);
    //wait for MaxWaitInMs to get an event from _c.MessageReceived
    //return the message or null if no message was received in response
  }
}

Wenn wir Ihnen Nachrichten senden, die IChannel manchmal eine Antwort gibt, je nachdem, welche Art von Message gesendet wurde, durch die Erhöhung der MessageReceived Veranstaltung. Die event-Argumente enthalten, die die Nachricht von Interesse.

Möchte ich Sender.Send() Methode zu warten, für eine kurze Zeit zu sehen, wenn dieses Ereignis ausgelöst wird. Wenn dem so ist, werde ich zurück sein MessageEventArgs.Message Eigenschaft. Wenn nicht, ich eine null zurück Message.

Wie kann ich das warten auf diese Weise? Ich würde es vorziehen, nicht zu haben, tun Sie das threading-Beinarbeit mit ManualResetEvents und so, kleben regelmäßige events wäre optimal für mich.

  • "...lieber nicht zu tun haben, das threading-Arbeit..." - Soll das interpretiert werden, wie Sie Ihre app läuft vollständig in einem einzigen thread?
  • Nein, mit worker-threads und so ist fein, und Sie sind verwendet an anderer Stelle in der app (zum Beispiel IChannel-Umsetzung erzeugt einen neuen thread zum schreiben in einen stream). Ich möchte bleiben mit der syntaktischen Zucker von Delegaten und Ereignisse, obwohl, und nicht die lower-level -System.Threading.
  • Delegaten und Ereignisse sind nicht syntaktische Zucker für den Durchzug. Ereignisse werden ausgelöst und behandelt, die auf dem gleichen thread (es ist syntaktischer Zucker über einem Funktionsaufruf, und auf die gleiche Weise funktioniert)
  • Sorry, ich wollte nicht Ausdrücken, dass sehr gut. In Teil, was ich Frage, ist, ob ich das kann effektiv ein ManualResetEvent durch kleben mit events und delegates.
InformationsquelleAutor Evan Barkley | 2010-05-12
  1. 15

    Verwenden AutoResetEvent.

    Gib mir ein paar Minuten und ich werde werfen gemeinsam eine Probe.

    Hier ist es:

    public class Sender
{
    public static readonly TimeSpan MaxWait = TimeSpan.FromMilliseconds(5000);

    private IChannel _c;
    private AutoResetEvent _messageReceived;

    public Sender()
    {
        //initialize _c
        this._messageReceived = new AutoResetEvent(false);
        this._c.MessageReceived += this.MessageReceived;
    }

    public Message Send(Message m)
    {
        this._c.Send(m);
        //wait for MaxWaitInMs to get an event from _c.MessageReceived
        //return the message or null if no message was received in response


        //This will wait for up to 5000 ms, then throw an exception.
        this._messageReceived.WaitOne(MaxWait);

        return null;
    }

    public void MessageReceived(object sender, MessageEventArgs e)
    {
        //Do whatever you need to do with the message

        this._messageReceived.Set();
    }
}
    • Ich weiß, dass ich dies mit einem ManualResetEvent, aber wie ich schon sagte ("ich würde es vorziehen, nicht zu haben, tun Sie das threading-Beinarbeit mit ManualResetEvents"), ich hoffe, es gibt eine andere Möglichkeit.
    • Sorry, ich habe übersehen, dass in deinem original-post. Selbst wenn Sie erstellen Sie einen Delegaten und rufen BeginInvoke haben Sie immer noch eine callback-Methode, und Sie haben immer noch die manuelle Synchronisierung des threads irgendwie. Obwohl, das IAsyncResult-Instanz sollte eine WaitHandle für Sie, die würde, die Dinge zu vereinfachen ein wenig, aber nicht viel.
    • Dieses sieht wie es wird den trick tun, und es ist ungefähr so einfach, wie ich bekommen kann, nehme ich an. Danke!
    • Noch eine Frage: mit dieser Methode, es sieht aus wie ich haben Sender.MessageReceived speichern Sie einige Daten (sagen wir, in einem Instanz-Feld), so dass Sender.Send können es später. (Um dies zu sehen, versuchen, herauszufinden, wie Sie würde wieder etwas anderes als null aus Sender.Send.) Ist es eine eigenständige Art und Weise, es zu tun, aus der Sender.Send Methode?
    InformationsquelleAutor Toby
  2. 1

    Haben Sie versucht, die Zuordnung der Funktion zum Aufruf asynchron zu einer delegieren, dann beschwört den mydelegateinstance.BeginInvoke?

    Linky für die Referenz.

    Mit dem unten angeführten Beispiel, rufen Sie einfach

    FillDataSet(ref table, ref dataset);

    und dann funktioniert es wie von Geisterhand. 🙂

    #region DataSet manipulation
///<summary>Fills a the distance table of a dataset</summary>
private void FillDataSet(ref DistanceDataTableAdapter taD, ref MyDataSet ds) {
  using (var myMRE = new ManualResetEventSlim(false)) {
    ds.EnforceConstraints = false;
    ds.Distance.BeginLoadData();
    Func<DistanceDataTable, int> distanceFill = taD.Fill;
    distanceFill.BeginInvoke(ds.Distance, FillCallback<DistanceDataTable>, new object[] { distanceFill, myMRE });
    WaitHandle.WaitAll(new []{ myMRE.WaitHandle });
    ds.Distance.EndLoadData();
    ds.EnforceConstraints = true;
  }
}
///<summary>
///Callback used when filling a table asynchronously.
///</summary>
///<param name="result">Represents the status of the asynchronous operation.</param>
private void FillCallback<MyDataTable>(IAsyncResult result) where MyDataTable: DataTable {
  var state = result.AsyncState as object[];
  Debug.Assert((state != null) && (state.Length == 2), "State variable is either null or an invalid number of parameters were passed.");

  var fillFunc = state[0] as Func<MyDataTable, int>;
  var mre = state[1] as ManualResetEventSlim;
  Debug.Assert((mre != null) && (fillFunc != null));
  int rowsAffected = fillFunc.EndInvoke(result);
  Debug.WriteLine(" Rows: " + rowsAffected.ToString());
  mre.Set();
}
    • +1: gute Entscheidung, IMO. Im Grunde implementiert ManualResetEvent für Sie.
    • Ich bin mir nicht sicher, ich verstehe diese Antwort. Können Sie zeigen, was Sie bedeuten im Zusammenhang mit diesem Beispiel?
    • Ich ll update es mit einem Beispiel aus meinem eigenen code (der funktioniert einwandfrei) 2 Sekunden..
    • Hmm.. ich Schätze das konkrete Beispiel, das Sie zur Verfügung gestellt, aber diese ist immer noch Recht kryptisch für mich. Und dieses scheint die Verwendung ManualResetEvents direkt zu. =/ Auch dieses Beispiel scheint nicht zu sein, Analog zu der situation in meinem Beispiel, da gibt es einen Aufruf zu EndLoadData erscheint, um einige der verborgenen Dinge.
    • Es gibt keine Möglichkeit, um die reset-Ereignisse, die ich sehen kann (welcher Art auch immer Sie sein können), was Sie für Fragen erfordert threading, indem es die Natur, daher ist es unvermeidlich. Es gibt nichts zu fürchten, vor allem mit diesem Beispiel - das ist die Schönheit dieses Entwurfsmuster, ich bin demonstrieren - es ist völlig autarke, kein threading Probleme (er versteckt Sie hinter der async-Aufruf)!
    • Ich hatte vergessen, nehmen, rufen, um Endloaddata für das Beispiel, tut mir Leid, da Sie es sah, habe ich den beginloaddata auch 🙂
    • Gotcha. Nur um klar zu sein, Ihrem Vorschlag ist, dass in meinem Sender.Send Methode, ich Tue das folgende: (1) ordnen Sie die IChannel.Send Aufruf eines Delegaten, (2) dann asynchron aufrufen, die mit BeginInvoke, (3) führen sowohl eine wait-handle und einen Verweis auf den Delegaten aufgerufen wird, (4) dann WaitOne auf das wait-handle, und (5) weiter auf einmal die .Set aufgerufen, die Delegierten?
    • Das würde nicht funktionieren, obwohl, was Sie nennen würde Set? Wenn Sie rief es in die delegieren, wie würden Sie eine Garantie für jede Art von warten? Und wenn Sie immer Sleep(timeout) Sie schlafen werde, egal was, zu besiegen alle das komplizierte einfädeln.
    • Yep. @Ron: Sie brauchen nicht zu warten, wenn Sie nicht müssen, das ist der springende Punkt! 🙂 die .Set wird nur aufgerufen, nachdem EnvInvoke da EndInvoke ist ein blockierender Aufruf. Dies bedeutet .Set aufgerufen wird, zum frühestmöglichen Zeitpunkt.

    InformationsquelleAutor Geoff
  3. 0

    Vielleicht Ihre Methode MessageReceived sollte einfach die Flagge, unter der ein Wert für eine Eigenschaft der IChannel-Schnittstelle, die bei der Implementierung von INotifyPropertyChanged event-handler, so dass Sie würde empfehlen, wenn die Eigenschaft geändert wird.

    By doing so, Ihre Absender-Klasse konnte Durchlaufen, bis die max Wartezeit abgelaufen ist, oder wenn das PropertyChanged-Ereignis-handler Auftritt, brechen Sie die Schleife erfolgreich. Wenn die Schleife nicht kaputt zu bekommen, dann wird die Nachricht gilt als nie erhalten.

    • Das funktionieren würde, aber es würde die änderung der IChannel Vertrag, das scheint weniger als wünschenswert. Aus einem design-Sicht, ich glaube nicht, dass IChannel sollte zu ändern, da Sie nichts über die Art und Weise Ihrer Implementierung verwenden, es hat sich hier geändert.
    InformationsquelleAutor Will Marcouiller
  4. 0

    Nützlich Probe mit AutoResetEvent:

        using System;
    using System.Threading;

    class WaitOne
    {
        static AutoResetEvent autoEvent = new AutoResetEvent(false);

        static void Main()
        {
            Console.WriteLine("Main starting.");

            ThreadPool.QueueUserWorkItem(
                new WaitCallback(WorkMethod), autoEvent);

            //Wait for work method to signal.
            autoEvent.WaitOne();
            Console.WriteLine("Work method signaled.\nMain ending.");
        }

        static void WorkMethod(object stateInfo) 
        {
            Console.WriteLine("Work starting.");

            //Simulate time spent working.
            Thread.Sleep(new Random().Next(100, 2000));

            //Signal that work is finished.
            Console.WriteLine("Work ending.");
            ((AutoResetEvent)stateInfo).Set();
        }
    }
    InformationsquelleAutor Yuliia Ashomok
  5. -1

    WaitOne wirklich das richtige Werkzeug für diese Aufgabe. Kurz gesagt, Sie wollen warten, zwischen 0 und MaxWaitInMs Millisekunden, um einen job zu vervollständigen. Sie haben wirklich zwei Optionen, Umfrage für den Abschluss oder die Synchronisierung der threads mit einigen Konstrukt, das warten kann eine beliebige Menge von Zeit.

    Da bist du gut bekannt, der richtige Weg, dies zu tun, für die Nachwelt poste ich die polling-version:

    MessageEventArgs msgArgs = null;
var callback = (object o, MessageEventArgs args) => {
    msgArgs = args;
};

_c.MessageReceived += callback;
_c.Send(m);

int msLeft = MaxWaitInMs;
while (msgArgs == null || msLeft >= 0) {
    Thread.Sleep(100);
    msLeft -= 100; //you should measure this instead with say, Stopwatch
}

_c.MessageRecieved -= callback;
    InformationsquelleAutor Ron Warholic
Schreibe einen Kommentar