Wie am effizientesten Daten von einem Thread in einen anderen bekommen?

PhilippM

Hallo,

ich brauche mal ein paar Meinungen zu einer Designentscheidung.

Gegeben sei folgende Situation:
-Das Hauptprogramm habe einen größeren Satz Daten (etwa 400 floats) irgendwo gespeichert.
-Das Hauptprogramm habe nur einen Thread. Aus diesem rufe es eine Callbackfunktion in einem Plugin auf.
-Das plugin darf die Daten aus dem Hauptprogramm nur lesen, wenn es "dran ist", das heißt, nur innerhalb der Callbackfunktion.
-Nach dem Einlesen macht die Callbackfunktion auf den Daten irgendwas und schreibt sie anschließend ins Netzwerk raus
-Während die callbackfunktion aufgerufen wird, muss das Hauptprogramm warten, bis das plugin aus eben dieser Funktion returned.

Im Augenblick läuft das zum größten Teil synchron, ich sehe aber schon ganz deutlich das bottleneck, das dass Hauptprogramm warten muss, bis das Plugin in seiner Callbackfunktion alle Daten verknurpselt hat.

Daher geht meine Überlegung dahin:
-In der Callbackfunktion nur die Daten einlesen, irgendwo im Memory ablegen, und sofort returnen.
-Alle Berechnungen auf den Daten in separatem Thread machen.

Das erfordert, dass ich die Daten aus der Callbackfunktion in den Thread schieben muss.

Hier ist jetzt die Frage: Wie mache ich das am effizientesten?
Im Grunde muss eine Liste von etwa 400-500 int=>float Wertepaaren oder eine map<int, float> threadsicher übergeben werden.

Zur Liste gefällt mir besonders die "Lockfreie Queue" von Sutter, die hier beschrieben ist http://www.drdobbs.com/high-performance-computing/210604448 leider setzt sie atomic<> von C++0x voraus, was ich auf gcc 4.2 noch nicht habe.

Grundsätzlich bin ich für alle Möglichkeiten offen, aber eine Producer-Consumer-Queue erscheint mir recht logisch.

Andere Möglichkeit wäre einfach eine map oder list und eine Mutex mit Schreibpriorität... Das hab ich in pthread schon gesehen, wirds bestimmt auch in boost::thread geben.

Noch mehr Ideen?

Philipp

PhilippM

*Bump*

126 Hits und keine Antwort?

Ich habe mir in der zwischenzeit mal boost::atomic angeschaut, was ja wohl die Vorlage fürs kommende C++0x std::atomic ist. Damit hätte ich das Problem schonmal plattformübergreifend erschlagen.

Daher scheint mir die lock-free queue ein guter Weg, Messages zwischen den Threads auszutauschen.

Einwände, Vorschläge?

Gruß,
Philipp

brotbernd

PhilippM schrieb:

Das erfordert, dass ich die Daten aus der Callbackfunktion in den Thread schieben muss.

Ich verstehe nicht was du mit schieben meinst. Ein Thread kann doch irgendwo Daten erzeugen und ein anderer arbeiten mit genau diesen Daten weiter. Es muss nur darauf geachtet werden, dass die Daten auch lang genug leben.

int hauptthread()
{
  daten d;
  thread t(d);
  t.join();
  return 0;
}
int hauptthread2()
{
  daten* d = new daten;
  thread t(d);
  return 0;
}
int hauptthread3()
{
  daten d;
  thread t(d); // kopie
  return 0;
}
int hauptthread4()
{
  daten d;
  thread t(std::move(d));
  return 0;
}

knivil

Grundsätzlich bin ich für alle Möglichkeiten offen, aber eine Producer-Consumer-Queue erscheint mir recht logisch.

Fuer welches Problem? Du hast das leider noch nicht beschrieben, nur deine Loesung bzw. aktuelle Realisierung.

ich sehe aber schon ganz deutlich das bottleneck

Ich nicht. Hast du gemessen, wie kommst du zu dieser Annahme, welche Zeitkriterien sollen ueberhaupt erfuellt werden?

Zur Liste gefällt mir besonders die "Lockfreie Queue" von Sutter

Bevor du damit anfaengst, solltest du dich erstmal mit Multitreaded auseinandersetzen.

größeren Satz Daten ... 400-500 int=>float Wertepaaren

Also etwa 32 kByte? Wie lange dafuer wohl ein memcpy braucht ... vielleicht 8'000 Takte ... wieviel GHz hat dein Prozessor ...

zeusosc

Der Lock Free Queue von Sutter geht davon aus das der consuming thread "one step behind" ist. Das man in eine Strucktur den Ptr des nächsten elementes legt um somit ein "dynamisches" Array zu erhalten ist auch alte Schule.

Mich würde der Nächste Artikel interessieren :"Next month, we will consider how to generalize the queue for multiple producer and consumer threads."

Leider habe ich jetzt (um diese Zeit) den link net gefunden. Falls diesen jemand parat hat mal bÜdde posten,...

mfg

brotbernd

Wahrscheinlich dieser hier?
http://www.drdobbs.com/cpp/211601363
Ansonsten listet der Herb auch seine Artikel auf seiner Seite http://gotw.ca/publications/index.htm