4. Kommunikation zwischen Thread: Benachrichtigung?

Kommunikation zwischen Thread: Benachrichtigung?

  • N

    CStoll schrieb:

    Auch bei PostMessage() muß der Hauptthread abfragen, ob eine Nachricht angekommen ist - der Vorteil hier ist, daß ein WinAPI-Programm normalerweise ständig in der Nachrichtenschleife läuft und damit auch Nachrichten verarbeitet, die per PostMessage() und Kollegen reingekommen sind.

    der vorteil von 'PostMessage()' ist, dass der sender nicht wartet bis der empfänger die msg aus der queue gesaugt hat. also kein blocking des senders.

    0
  • C

    net schrieb:

    CStoll schrieb:

    Auch bei PostMessage() muß der Hauptthread abfragen, ob eine Nachricht angekommen ist - der Vorteil hier ist, daß ein WinAPI-Programm normalerweise ständig in der Nachrichtenschleife läuft und damit auch Nachrichten verarbeitet, die per PostMessage() und Kollegen reingekommen sind.

    der vorteil von 'PostMessage()' ist, dass der sender nicht wartet bis der empfänger die msg aus der queue gesaugt hat. also kein blocking des senders.

    Der Sender blockiert auch nicht, wenn er das Hauptprogramm über eine globale Variable oder einen Event informiert 😉 (und dem OP war eher wichtig, daß das Hauptprogramm (also der Empfänger) nicht blockiert)

    0
  • N

    CStoll schrieb:

    Sender blockiert auch nicht, wenn er das Hauptprogramm über eine globale Variable oder einen Event informiert 😉 (und dem OP war eher wichtig, daß das Hauptprogramm (also der Empfänger) nicht blockiert)

    klar, ich wollt' nur die liste der vorteile von 'PostMessage()' ergänzen...

    0
  • S

    Na gut, ich denke, dann sind alle Möglichkeiten abgeklärt. Ich werde beim guten alten pollen bleiben .. Dank für alle Antworten!

    0
  • Mod

    "Pollen" würde ich nicht machen. Ich würde ein Event verwenden und als Funktion in der Nachrichtenschleife MsgWaitForMultipleObjects verwenden!

    0
  • N

    Martin Richter schrieb:

    MsgWaitForMultipleObjects

    er hat doch geschrieben dass der thread nicht warten soll...

    0
  • Mod

    Das tut er mit dieser Funktion ja auch nicht. Es ist IMHO nur besser als pollen und kostet keine weitere Systemzeit. Ein Event, das vom Worker gesetzt wird, kann damit liecht geprüft werden und man blockiert die Nachrichtenschlefe nicht und man bekommt dennoch wunderbar alle Nachrichten mit.

    Just my 2 cents!

    0
  • S

    Hmm, ich habe das genau so interpretiert wie net. Ein paar Versuche von mir mit Events (und postMessage) haben nämlich gezeigt, dass man dadurch zwar auf das Ende eines Threads (oder eines Zwischenzustands) warten kann, aber nicht der Ursprungsthread komplett asynchron benachrichtigt wird.

    Könntest Du vielleicht ein Minimalbeispiel geben, wo Thread1 ungehindert weiterläuft, bis er durch eine Notifikation über etwas informiert wird..?

    0
  • Mod

    Vielleicht reden wir aneinander vorbei.
    Man nehme ein Event, das den gewünschten Zustand im Workerthread signalisiert.

    while (AsLangAsWeHaveToDoThis())
{
    if (WaitForSingleObject(hEvent,0)==WAIT_TIMEOUT)
    {
        // Do the stuff that need to be done
        // The Workerthread ist stil executing
        ...
    }
    else
    {
        // The worker thread has done its job
        ...
    }
}

    MsgWaitFor... benutze ich dann wenn der Mainthread auch noch eine Nachrichtenschleife nutzt.

    0
  • S

    Aha, ich glaube, ich habe einfach WaitForSingleObject falsch benutzt und ihn unendlich lang warten lassen. Demnach tastet er nur das Event ab und macht dann weiter. Ich werd das gleich mal probieren, Danke.

    0
  • Mod

    Serethos schrieb:

    Aha, ich glaube, ich habe einfach WaitForSingleObject falsch benutzt und ihn unendlich lang warten lassen. Demnach tastet er nur das Event ab und macht dann weiter. Ich werd das gleich mal probieren, Danke.

    So ist es. Und mit der Msg... Version kann man sogar noch Nachrichten in seine MessageLoop einschliessen und dann sogar INFINTE beim warten wählen.

    0
Anmelden zum Antworten