Ich beschreibe vielleicht erst mal, was ich erreichen will: Ich schicke Nachrichten zu einem Busteilnehmer, der dann kurz darauf eine Antwort zurücksendet. Die Antwort kann auch auf mehrere Nachrichten aufgeteilt sein.

Jetzt habe ich eine Klasse Receiver von TThread abgeleitet, die in einer Endlosschleife alle Busnachrichten empfängt und in eine Queue (hab deque verwendet) einfügt. Außerdem besitzt die Klasse Receiver eine Methode getMessages, die eine Kopie der Queue zurückgibt, und die Queue anschließend leert.

void __fastcall Receiver::Execute()
{
while(1) {
    myOpto->Receive(erg,source,newmessage,cont,999);
    MostMessage message;
    message.setMessage(erg);
    message.setSource(*source);
    messagequeue.push_back(message);
    }
}

deque<MostMessage> Receiver::getMessages(bool clear)
{
deque<MostMessage> erg;
erg = messagequeue;
if(clear) messagequeue.clear();
return erg;
}

Wenn ich jetzt von einem Busteilnehmer was wissen will, sende ich von meinem Form die Anfrage auf den Bus, warte eine gewisse Zeit, rufe dann getMessages vom Receiver auf und suche in der Nachrichtenqueue nach der Antwort.

Nun das Problem: In der Queue, die ich von getMessages bekomme, fehlen manchmal die gesuchten Nachrichten, obwohl sie ziemlich sicher empfangen wurden.

Wie ist das überhaupt genau mit den Threads? Alles was ich in die Methode "Execute" schreibe, wird parallel zum restlichen Programmablauf ausgeführt. Aber wie verhält es sich mit den anderen Methoden, wie beispielsweise getMessages? Muss ich vielleicht Vorkehrungen treffen, die verhindern, dass Execute und getMessages zeitgleich auf die Queue zugreifen?

Ich danke euch schon jetzt
Stefan

Ich hab jetzt versucht, die kritischen Stellen durch critical Section zu schützen. Dennoch besteht mein Problem weiterhin.

Hier nochmal mein Problem etwas genauer:

Hier ist ein Beispiel für eine Methode, die getData aus der Klasse Receiver aufruft. Es wird also ein Befehl gesendet und kurze Zeit später nach der Antwort in den empfangenen Nachrichten gesucht:

bool Most::isTA(void)
{
bool erg = false;
AnsiString HEXMessage = "40" + InstIdTuner + "4561";
myOptolyzer->Send(HEXMessage.c_str(), NodeAdressTuner);
Sleep(500);
String searchstring = "40" + InstIdTuner + "456C";
String result;
result = myReceiver->getData(searchstring);
if (result != "nix")
   {
    if (result == "1") erg = true;
   }
return erg;
}

Dummerweise kommt von getData sehr häufig "nix" zurück. Ich hab auch schon Sleep-Zeit variiert, daran liegt es nicht.

Hier die Methoden getMessages und getData. getMessages holt die aktuell empfangenen Nachrichten ab und löscht die Queue anschließend. getData sucht in den Messages nach der richtigen Message.

deque<MostMessage> Receiver::getMessages(bool clear)
{
deque<MostMessage> erg;
Sperre->Acquire();
try {
   erg = messagequeue;
   if(clear) messagequeue.clear();
   }
__finally {
   Sperre->Release();
   return erg;
   }
}

String Receiver::getData(String header)
{
deque<MostMessage> messages;
String temp;
String erg = "nix";
messages = getMessages(true);
for(unsigned int i=0;i<messages.size();i++)
        {
        temp = (messages.at(i)).getMessage();

        if (temp.SubString(1,header.Length()) == header)
                {
                int length = 0;
                String lengthstring;
                lengthstring = temp.SubString(header.Length() + 1, 2);
                lengthstring = "0x" + lengthstring;
                length = lengthstring.ToInt();
                erg = temp.SubString(header.Length() + 3, length * 2);
                }
        }
return erg;
}

Auf meinem Form hab ich einen Button, wo ich mir die aktuellen Messages augeben lassen kann:

void __fastcall TForm1::Button2Click(TObject *Sender)
{
deque<MostMessage> messagequeue;
messagequeue = myMost->myReceiver->getMessages(true);
Memo1->Clear();
for (unsigned int i=0;i<messagequeue.size();i++)
   {
   AnsiString line;
   line = (messagequeue[i]).getMessage();
   Memo1->Lines->Add(line);
   }
}

Das seltsame ist nun:
Bei der Methdoe "isTA" kommt kein Ergebnis heraus. Wenn ich aber kurz danach den Button drücke, sehe ich die gesuchte Message. Eigentlich dürften aber in der Queue nach dem Aufruf von getMessages überhaupt keine Nachrichten mehr drin sein.

Kann mir jemand sagen, woran das liegen könnte?

Grüße
Winzler

Ich empfehle dir, eine Klasse von der Queue privat abzuleiten, und die Zugriffe threadsicher zu machen (Getter- und Setter-Funktionen, die bei Lese / Schreibzugriffen auf die Queue die Critical Section für sich beanspruchen)

Anschliessend im Rahmen des Threads die Threadsafe queue verwenden.

Alternativ kannst du diese Queue hier verwenden. Dann musst du aber jeden Zugriff auf die Queue durch CriticalSections absichern.

Sofern die Queue eine Klasse der Standard Template Libary ist, ist die definitiv Threadsicher!
CriticalSections, Semaphoren etc. sind da überflüssig!

Dann wirkt manchmal statt nur "Sleep()" sowas hier Wunder:

...
Sleep(500);
Application->ProcessMessages();
...

3.1. Du hast den Aufruf "messages = getMessages(true);".
3.2. In deiner getMessages()-Funktion machst du ein "if(clear) messagequeue.clear();".
3.3. Dann hast du die for-Schleife "for(unsigned int i=0;i<messages.size();i++)", messages.size() ist aber 0 wgen 3.2., du gehst also nie in die for-Schleife.
3.4. Wenn ich jetzt nix übersehen habe, würde ich dir auch immer "nix" zurückgeben wenn ich deine Funktion wäre.

Ich hab das mal so doof nummeriert, damit ich selbst den durchblick behalte

Noch als kleiner Gedankengang für mich: Warum gibst du eigentlich nicht einfach einen Zeiger auf deine Queue zurück statt ner Kopie?

Sofern die Queue eine Klasse der Standard Template Libary ist, ist die definitiv Threadsicher!
CriticalSections, Semaphoren etc. sind da überflüssig!

Quelle?

el Clio schrieb:

Dann wirkt manchmal statt nur "Sleep()" sowas hier Wunder:

...
Sleep(500);
Application->ProcessMessages();
...

Wieso?

3.4. Wenn ich jetzt nix übersehen habe, würde ich dir auch immer "nix" zurückgeben wenn ich deine Funktion wäre.

Du hast was übersehen:

erg = messagequeue;

Noch als kleiner Gedankengang für mich: Warum gibst du eigentlich nicht einfach einen Zeiger auf deine Queue zurück statt ner Kopie?

Weil die Queue änderungen unterworfen ist, und man ja nicht immer den Thread wieder unterbrechen will mit kurzen zugriffen? Man sollte nie Zeiger auf klasseninterne Datenstrukturen zurückliefern. Das gefährdet die Integrität

el Clio schrieb:

Sofern die Queue eine Klasse der Standard Template Libary ist, ist die definitiv Threadsicher!
CriticalSections, Semaphoren etc. sind da überflüssig!

Quelle?

Weiß nicht mehr ganz genau, meine aber STL doku.

junix schrieb:

el Clio schrieb:

Dann wirkt manchmal statt nur "Sleep()" sowas hier Wunder:

...
Sleep(500);
Application->ProcessMessages();
...

Wieso?

Pure Erfahrung. Grade bei dem vcl-Thread-Zeugs ist ein abarbeiten der der Nachrichten ab und an mal sinnvoll.
Hatte auch schon mal ein ähnliches Problem, daß ich was losgeschickt habe, mit Sleep(), also blockierend gewartet habe und dann die Antwort abfragen wollte. Ergebnis: Mal gings, mal nicht.
Durch Application->ProcessMessages(), also durch schäbiges pollen gings dann wie von Zauberhand.

junix schrieb:

3.4. Wenn ich jetzt nix übersehen habe, würde ich dir auch immer "nix" zurückgeben wenn ich deine Funktion wäre.

Du hast was übersehen:

erg = messagequeue;

Mist! Ich wusste, daß sowas kommt

junix schrieb:

Noch als kleiner Gedankengang für mich: Warum gibst du eigentlich nicht einfach einen Zeiger auf deine Queue zurück statt ner Kopie?

Weil die Queue änderungen unterworfen ist, und man ja nicht immer den Thread wieder unterbrechen will mit kurzen zugriffen? Man sollte nie Zeiger auf klasseninterne Datenstrukturen zurückliefern. Das gefährdet die Integrität

Ja, ok! Hab nix gesagt! Je nach größe der Queue und je nach Größe der vorhandenen recourcen ist es aber manchmal sinnvoller die integrität zu gefährden, dafür aber auf die ewigen kopierereien zu verzichten. So dachte ich eigentlich

Egal. Waren alles nur so Gedanken!

Unter dem Anspeckt, daß er nun doch in die for-Schleife läuft würde mich mal interessieren, was so debug-mäßig in temp steht, also ob da vernündtiger Inhalt ankommt. Als nächstes würde mich dann interessieren, was der SubString() (von der Funktion her isses klar, aber vom Inhalt her nicht) liefert und ob der Vergleich klappt.

Nebenbei: Sehe ich das richtig, daß "erg" am ende immer neu gesetzt wird, also beim return im besten Fall nur der Inhalt der letzten message steht?

junix schrieb:

el Clio schrieb:

Sofern die Queue eine Klasse der Standard Template Libary ist, ist die definitiv Threadsicher!
CriticalSections, Semaphoren etc. sind da überflüssig!

Quelle?

Weiß nicht mehr ganz genau, meine aber STL doku.

...konnte aber keinen Hinweis auf Threadsicherheit finden in der BCB-Dokumentation... und es wäre auch unlogisch, Threadsicherheit standardmässig einzubinden. Es gibt allerdings z.B. TThreadLIst die Threadsicher sein soll... Auf jeden Fall gilt im Zweifel immer die deffensivere Annahme zu treffen. Das schlechteste was dir da passieren kann ist, dass du doppelte Threadsicherheit implementierst. Birgt aber weniger Nachteile als keine Threadsicherheit...

el Clio schrieb:

junix schrieb:

el Clio schrieb:

Dann wirkt manchmal statt nur "Sleep()" sowas hier Wunder:

...
Sleep(500);
Application->ProcessMessages();
...

Wieso?

Pure Erfahrung. Grade bei dem vcl-Thread-Zeugs ist ein abarbeiten der der Nachrichten ab und an mal sinnvoll.

... denn sie wissen nicht was sie tun ...

Auch beim VCL zeugs ist ein neuer Thread ein neuer Thread der ein neuer Thread ist. Da braucht es keine Abarbeitung von Nachrichten, ausser der Thread verwendet z.B. wieder ein Control auf einem Formular. Dann ists aber ohnehin müssig, irgendwas in einen Thread zu verlagern.

el Clio schrieb:

Hatte auch schon mal ein ähnliches Problem, daß ich was losgeschickt habe, mit Sleep(), also blockierend gewartet habe und dann die Antwort abfragen wollte. Ergebnis: Mal gings, mal nicht.
Durch Application->ProcessMessages(), also durch schäbiges pollen gings dann wie von Zauberhand.

Unter verwendung eines COntrols das über die Nachrichtenschleife der Applikation geht, gluab ich das sofort...

el Clio schrieb:

junix schrieb:

Noch als kleiner Gedankengang für mich: Warum gibst du eigentlich nicht einfach einen Zeiger auf deine Queue zurück statt ner Kopie?

Weil die Queue änderungen unterworfen ist, und man ja nicht immer den Thread wieder unterbrechen will mit kurzen zugriffen? Man sollte nie Zeiger auf klasseninterne Datenstrukturen zurückliefern. Das gefährdet die Integrität

Ja, ok! Hab nix gesagt! Je nach größe der Queue und je nach Größe der vorhandenen recourcen ist es aber manchmal sinnvoller die integrität zu gefährden, dafür aber auf die ewigen kopierereien zu verzichten. So dachte ich eigentlich

... Auch nicht falsch. Ich allerdings gehe dabei meist dazu über, das ich Datagramme einzeln aus besagtem Puffer hole und sie verarbeite. Das verhindert mir auch merkürdige Stacking-Effekte bei der Kommunikation...

[/quote]Nebenbei: Sehe ich das richtig, daß "erg" am ende immer neu gesetzt wird, also beim return im besten Fall nur der Inhalt der letzten message steht?[/quote]Wo siehst du denn sowas?

el Clio schrieb:

Nebenbei: Sehe ich das richtig, daß "erg" am ende immer neu gesetzt wird, also beim return im besten Fall nur der Inhalt der letzten message steht?

Wo siehst du denn sowas?

Bei

erg = temp.SubString(header.Length() + 3, length * 2);

Nur dann, wennauch Nachrichten in der Queue waren...

Ja eben! Und für jede Nachricht neu. Also steht entweder "nix" drin oder eben das Ergebnis aus dem temp.SubString(), wobei in temp doch die letzte Nachricht enthält.

Irgendwie erschließt sich mir grad der Sinn nicht wirklich!

Er will entweder die Nachricht oder "nix" drinne stehen haben. Wenn er jetzt die Datagramme überprüft wird das Ergbenis zunächst mit "nix" initialisiert. Geht dann aber alle datagramme durch. Wenn er den header findet, weist er diesen dem Ergebnis zu. Ansonsten kommt nix zurück.?

Und wenn mehrere Header drin sind?

Ich habe mal ein

Application->ProcessMessages();

eingebaut, und siehe da, es wirkt tatsächlich Wunder! Auch wenn ich keine Ahnung habe warum...

Ich werde aber trotzdem den Tipp von junix realisieren, und eine threadsichere Klasse von der Queue ableiten. Schon allein wegen des Lerneffektes.

Vielen Dank erst mal

Winzler

und siehe da, es wirkt tatsächlich Wunder!

Na sag ich ja!

So sieht die Definition aus:

class MessageQueue : private deque<MostMessage>
{
private:
        TCriticalSection* Sperre;
public:
        MessageQueue(void);
        void push(MostMessage);
        MostMessage at(int i);
        void clear(void);
        int size(void);
        MessageQueue get(void);
};

Und so die Implementierung:

MessageQueue::MessageQueue(void)
{
   Sperre = new TCriticalSection;
}

void MessageQueue::push(MostMessage message)
{
   Sperre->Acquire();
   push_back(message);
   Sperre->Release();
}

MostMessage MessageQueue::at(int i)
{
   Sperre->Acquire();
   MostMessage erg = deque<MostMessage>::at(i);
   Sperre->Release();
   return erg;
}

MessageQueue MessageQueue::get(void)
{
   Sperre->Acquire();
   MessageQueue erg;
   erg = *this;
   Sperre->Release();
   return erg;
}

void MessageQueue::clear(void)
{
   Sperre->Acquire();
   deque<MostMessage>::clear();
   Sperre->Release();
}

int MessageQueue::size(void)
{
   int erg;
   Sperre->Acquire();
   erg = deque<MostMessage>::size();
   Sperre->Release();
   return erg;
}

Die so erstellte Queue zeigt allerdings nicht die gewünschte Wirkung. Ich habe auch schon versucht, TCriticalSection *Sperre global zu machen, also quasi so:

TCriticalSection *s;    //globale Variable

MessageQueue::MessageQueue(void)
{
   Sperre = s;
}

Dann krieg ich folgende Warnung...

[Linker Warnung] Public symbol '_s' defined in both module C:\PROGRAMME\CBUILDER6\PROJECTS\DLLCALL.OBJ and C:\PROGRAMME\CBUILDER6\PROJECTS\MOST.OBJ

...und lauter Exceptions wenn ich mein Programm aufrufe.

Kann mir einer sagen, was ich da falsch mache? Wäre es möglich, die TCriticalSection static zu machen, damit sie für alle MessageQueues gilt?

Es reicht also völlig, die Sperre als privates Klassenelement zu implementieren. Die Einzigen die Aquire und Release aufrufen sind ja die Funktionen die auf die klasseninterne Liste zugreifen?

Was heisst "zeigt nicht die gewünschte Wirkung"?

In meiner Hauptanwendung gibts keine Schleifen. Meine Hauptanwendung ist lediglich ein Fenster mit Buttons, mit denen verschiedene Nachrichten verschickt werden können, deren Antwort dann ausgewertet wird.

Die CPU-Belastung schwankt so zwischen 5 und 10 Prozent.