STL-Queue Zugriffsprobleme
-
Achso, das ist komerziell...
-
Redhead schrieb:
Aus Performance-Gründen sind die STL-Container nicht threadsafe.
Eine Aufrufkombination wie:
Wert = Queue.front(); Queue.pop();kannst du nicht sinnvoll allein über den Container thread-safe machen. Der Container kann sinnvoll nur einzelne Operationen schützen. Angenommen die einzelnen Funktionen wären thread-safe (was sie bei vielen STL-Implementationen sind), dann hast du hier immer noch eine race-condition. Schließlich kann ein anderer Thread zwischen dem Aufruf von front() und pop() die Queue verändern.
Wenn es sich bei der Queue also um eine geteilte Ressource handelt, dann musst du sie extern schützen. Oder du musst die Queue wrappen und eine "apply"-Funktion anbieten, die z.B. ein Funktionsobjekt entgegennimmt und damit eine Reihe von Aufrufen schützen kann.Siehe z.B. Executing Around Sequences
-
Die STL container sind nicht threadsicher, klar.
Aber es gibt keinen Grund, die nicht threadsicher zu machen, wenn mans baucht ....
Prinzipiell musst alle Zugriffe Kapseln und Nen Lock(Mutex) davorschalten.
Die Mechanismen sind dann natuerlich nimmer plattformunabhaengig ... oder du verwendest ne lib die dir fuer mehrere Betriebssysteme die funktionlaitaeten mappt ....
Unter windows, schau mal nach "CriticalSection"
mit der pthread kenn ich mich ned so aus ...Ich verwend unter windows auch die STL extensiv in ner Multithreaded umgebung.
Ciao ...
-
Selbst wenn ein anderer Thread zwischen front() und pop() etwas in den Thread schieben würde, wäre das kein Problem. (logisch betrachtet - vorne ist ja wurscht, was hinten passiert.) Trotzdem hat der Queue damit Probleme.
Oder du musst die Queue wrappen und eine "apply"-Funktion anbieten, die z.B. ein Funktionsobjekt entgegennimmt und damit eine Reihe von Aufrufen schützen kann
Äh... was?
Wie man einen Lock/Mutex bastelt, kapiere ich ja eben nicht. Die Bücher, die sich hier stapeln auch nicht.
-
Wie man einen Lock/Mutex bastelt, kapiere ich ja eben nicht.
Ein beliebiges Einsteigerbuch zum Thema Multithreading sollte helfen.
Oder du musst die Queue wrappen und eine "apply"-Funktion anbieten, die z.B. ein Funktionsobjekt entgegennimmt und damit eine Reihe von Aufrufen schützen kann
Äh... was?
[/quote]
Es geht darum aus eine Seuqenz von Operationen eine atomare Operation zu machen. Wenn du allerdings nicht weißt, was ein Mutex/Lock/Monitor usw. ist, dann bringt es wenig hier weiter zu schreiben.
-
Ich frage mich wie man eine Multithreaded Anwendung schreiben kann ohne jemals was von nem Mutex/Lock gehört zu haben.
HEZ schrieb:
In einen Queue werden schnell viele Werte geschrieben und wieder ausgelesen. Aber anscheinend zu schnell und zu oft. Denn es passiert zu oft, dass gleichzeitig (Threads!) versucht wird, zu lesen und zu schreiben. Und das mag der Queue wohl nicht. Besonders die push()-Funktion reagiert mit trotziger Langsamkeit.
-
eViLiSSiMo schrieb:
Ich frage mich wie man eine Multithreaded Anwendung schreiben kann ohne jemals was von nem Mutex/Lock gehört zu haben.
Nun, man zieht einen Timer auf das Hauptformular... tja... fertig.
Aber gute Idee. Ich schmeiß das Projekt in den Papierkorb und sag meinem Chef, dass du gesagt hast, ich könne das nicht machen. Danke, hätte nicht gedacht, dass es so einfach geht.HumeSikkins schrieb:
Ein beliebiges Einsteigerbuch zum Thema Multithreading sollte helfen.
Ein beliebiges?! Da macht man sich die Mühe und kauft jedes verdammte Buch, in dem das Wort "Thread" vorkommt (wie ich es immer mache, wenn ich einen Timer auf das Formular ziehe) und dann sagst du, es hätte auch ein beliebiges getan??
Sich hier bitte irgendwas Versöhnliches zur Beruhigung vorstellen; mir fällt gerade nichts ein<
-
Kannst du den queue nicht einfach in einen Singelton stecken, der
sich dann merkt ob der queue gerade in Benutzung ist... ?Devil
-
Welche Timer verwendest du denn? Den mit SetTimer? Dann sollte es gar nicht zu Konflikten kommen.
-
vergiss die frage. war dumm von mir.
-
devil81 schrieb:
Kannst du den queue nicht einfach in einen Singelton stecken, der sich dann merkt ob der queue gerade in Benutzung ist... ?
Was würde denn dann passieren, wenn er in Benutzung ist? Das müsste man doch dann auch abfragen, oder?
-
-
-
Wer kommt als nächstes? bluehead?
Ich denke immer noch nicht, dass die Lösung eines einzelnen Teilproblems (der Kategorie "sieht ja niemand")den Aufwand größerer finanzieller und zeitlicher Ressourcen rechtfertigt... sicher ist die Synchronisierung von Threads ein sehr interessantes und wissenswertes Thema. Ich würde jedoch damit gerne warten, bis ich mal Zeit für Weiterbildungen habe.
-
Nun, man zieht einen Timer auf das Hauptformular... tja... fertig.
Dann wird deine Klassenbibliothek mit Sicherheit auch Synchronisationsprimitive bereit stellen. Hast du schon gesagt, mit welcher Klassenbibliothek du arbeitest?
-
Hmm, nein, habe ich nicht. Die Klassenbibliothek wäre die VCL, da ich den BCB6 benutze. Und da sich jetzt wohl jeder fragt, warum ich dann nicht im BCB-Forum gepostet habe: Meine Frage bezog sich ursprünglich ja nur auf den Queue der STL; die Sache mit den Threads war ja nur Beiwerk, um zu zeigen, dass beide Zugriffe wirklich gleichzeitig auftreten (können).
Es sieht nicht so aus, als würde die VCL in einem Timer Synchronisationsmethoden anbieten.
-
Dann musst du es halt in einem echten Thread laufen lassen.
Die VCL müsste das bieten...Devil
-
Die VCL bietet auch richtige Thread-Klassen an. Und dazu passend die Synchronisation. Ein Beispiel zu Threads sollte sich im %BCB%\Examples Ordner finden.
-
Das Lustige ist ja, dass ich vorher nen Thread hatte und nun auf den Timer umgestiegen bin. Der Grund: Zugriffskonflikte!
Aber jetzt habt ihr mir ja erklärt, worauf ich achten müsste. Ich versuche noch ein bisschen hier mit dem rumzuwurschteln, was ich habe und werde bei einem Fehlschlag doch wieder zurück zum (T)Thread gehen. (Ich hasse es, wieder zu früheren Versionen zurückzukehren! :))Erstmal danke!