Fremden Code gleichzeitig ausführen verursacht Fehler, obwohl er threadsafe sein soll
Hallo,
ich binde eine API von einem anderen Hersteller in meine Software ein. Diese API wird benutzt um mit einer Server Komponente über ein proprietäre Protokoll zu sprechen.
Die API ist nicht in der Lage simultane Verbindungen zum Server offen zu halten. D.h. jeder Aufruf der API wird sequentiell bearbeitet, auch wenn Anfragen parallel rein kommen. Der Hersteller der API behauptet auch, dass es kein Problem sei wenn mehrere Threads gleichzeitig Funktionen verwenden, da ja sowieso alles sequentialisiert wird.
Ich habe aber jedoch den Verdacht, dass da doch etwas nicht so ganz sauber läuft und es ab und an vorkommt, dass etwas "hängt". In der Log-Datei steht was von "Mutex" - ich denke zwei Threads blockieren sich gegenseitig bis zu einem Timeout.
Das Verhalten kann ich jetzt schlecht nachstellen, da es nur sehr selten auftritt. Aber ich könnte mir ein Testprogramm vorstellen, dass das provoziert.
Ich müsste dazu wissen ob es möglich Code absolut gleichzeitig auszuführen. Angenommen ich habe 2 Kerne im Prozessor. Kann ich es steuern wann hier Code gleichzeitig ausgeführt wird?
Gruß
joh.w
Ich denke nicht, dass es möglich ist, Code exakt gleichzeitig auszuführen, solange du nicht auf einem Echtzeitbetriebssystem bist. Unter Windows wird dir da der Prozess-Scheduler dazwischenfunken. Aber du kannst mehrere Threads synchronisieren, damit sie pseudo-gleichzeitig ausgeführt werden.
Gruß, Christian.
@TheBrainiac:
Ein Echtzeitsystem kann Code nicht gleichzeitig ausführen. Das können nur Multicoresysteme und dabei ist es egal ob es Echtzeitsysteme sind oder nicht.
@joh.w:
Erstelle einfach ein paar Threads und ballere die API damit zu. Dann siehst du relativ schnell, wo es ungereimheiten gibt. Vorzugsweise solltest du Multicore-CPU´s nutzen aber es muss in deinem Fall nicht mal sein.
Das mit dem zuballern will ich eben genau nicht. Da weiß ich schon jetzt was als Antwort kommt, wenn ich im Bug-Case dann reinschreibe "wenn ich eure API zuballere kommt der Fehler ..."
Würde es funktionieren, wenn ich mir zwei Threads mache, die auf den gleichen EventWaitHandle warten? Dann könnte ich von außen einen Knopf drücken und beide legen los.
Ich müsste halt nur sicher stellen, dass jeder Thread einer anderen CPU zugeordnet ist und demenstrechend auch gleichzeitig vom OS-Scheduler verteilt ist.
Vielleicht ist exakt gleichzeitiges feuern auch nicht unbedingt erforderlich. Würde glaube ich auch schon reichen, wenn der Code nicht allzu viele CPU-Takte voneinander entfernt ausgeführt wird.
Naja, ich probier mal rum. Danke derweil.
wenn-->
Der Hersteller der API behauptet auch, dass es kein Problem sei wenn mehrere Threads gleichzeitig Funktionen verwenden, da ja sowieso alles sequentialisiert wird.
Dann darf die Anzahl der Threads keine Rolle spielen.
Ich müsste halt nur sicher stellen, dass jeder Thread einer anderen CPU zugeordnet ist
Musst du nicht mal... setze einfach einige Calls gegen die Schnittstelle und mach ein paar Performancefressende schleifen dazwischen. Führe das mehrfach aus und wenn es irgendwann kracht, dann weißt du das was nicht stimmt.
Es ist bei Multithreading und Deadlock-/racing condition -Situationen eigentlich irrelevant ob diese auf mehreren Kernen laufen oder nicht, da der Sheduler keine Rücksicht darauf nimmt, ob der Thread nun fertig ist oder nicht... der hält ihn auch mitten drin auf und ruft den nächsten auf, egal ob der gerade im Lock-Scope ist oder nicht.
@TheBrainiac:
Ein Echtzeitsystem kann Code nicht gleichzeitig ausführen. Das können nur Multicoresysteme und dabei ist es egal ob es Echtzeitsysteme sind oder nicht.
Naja, was ich meinte ist, dass bei einem "normalen" OS der Scheduler ja die Planung für die Prozessorzeit übernimmt und ein Prozess darauf selbst (abgesehen von der Priorität) keinen Einfluss hat. Bei einem Echtzeit-OS bestimmt der Prozess ja selbst, wann er die Kontrolle abgeben will. Wenn man nun ein Multi-Core-Echtzeit-System hat, kann man Code gleichzeitig ausführen. Bei einem "normalen" OS kommt einem da der Scheduler evtl. dazwischen.
Gruß, Christian.
Bei einem Echtzeit-OS bestimmt der Prozess ja selbst, wann er die Kontrolle abgeben will.
Das kann man so verallgemeinert nicht sagen. Kommt ganz auf den Scheduler an.
"Echtzeit" heißt nur, dass man weißt, wie lange ein Task/Prozess braucht. Man kann genausogut Echtzeitsysteme mit präemtiven Scheduling haben - bei dem die Tasks/Prozesse unterbrochen werden können.
"Echtzeit" heißt nur, dass man weißt, wie lange ein Task/Prozess braucht. Man kann genausogut Echtzeitsysteme mit präemtiven Scheduling haben...
Mh, Okay. Hast recht, hab nochmal nachgeguckt. Hatte es irgendwie anders in Erinnerung =)
Das mit dem zuballern will ich eben genau nicht. Da weiß ich schon jetzt was als Antwort kommt, wenn ich im Bug-Case dann reinschreibe "wenn ich eure API zuballere kommt der Fehler ..."
Damit würde der Anbieter die Qualität der eigenen API stark in Frage stellen, wenn er Fehler bei einem Stresstest einfach ignorieren würde...
Hi joh.w,
ich sehe bei dem "Stresstest" auch keine Problematik. Ich würd es noch nicht einmal als Stresstest bezeichnen.
Die API wirbt damit, sie sei thread-safe. Nun kannst du mit 2 Threads vielleicht nur schwer nachweisen, dass sie es nicht ist. Aber mit 1000 Threads kannst du leicht nachweisen, dass sie nicht thread-safe ist.
Ob nun 2 oder 1000, eins wäre erbracht: ein Beweis, dass die API nich thread-safe ist!
beste grüße
zommi
Damit würde der Anbieter die Qualität der eigenen API stark in Frage stellen, wenn er Fehler bei einem Stresstest einfach ignorieren würde...
Das tut er. Wenn man einen Bug meldet, diskutiert man mindestens ein halbes Jahr mit denen herum ob es nun wirklich ein Fehler ist. Am Ende schieben se es immer auf etwas anderes.
Neulich wurde ein Deadlock innerhalb der API ausgelöst, wenn kurzzeitig (wenige Sekunden) das Netzwerk nicht verfügbar war. Habe alles artig dokumentiert und aufgezeigt wie man reproduziert und was es für Auswirkungen hat. Das Ende vom Lied war, dass die Jungs gesagt haben "Kuck, dass du ein redundantes Netz hast... Netzausfälle tolerieren wir nicht". Ganz toll. Ich mag den Laden nicht, aber mir bleibt hier nichts anderes übrig.
Das Ende vom Lied war, dass ich von außen erkennen muss dass es gerade zu einem Deadlock gekommen ist. Ich kann es eigentlich nur daran erkennen, dass solange wie der Timeout ist keine Daten kommen, aber auch keine Fehlermeldung. Danach muss ich eine Prozedur starten die alle Informationen in der Zwischenzeit versucht zu rekonstruieren. Ist recht aufwändig und dauert auch bis zu 2 Stunden... aber nur so kann ich Datenkonsistenz gewährleisten.
Traurig, aber wahr.
Dann bau halt nen threadsafe wrapper drumrum und schon hast du das problem in weniger als nem halben Jahr gelöst 😉
Ja. Das hab ich jetzt erstmal gemacht. Damit funktioniert es auch recht zuverlässig. Allerdings geht durch die Synchronisierung etwa 30% der Performance drauf. Das finde ich jetzt zwar nicht so glücklich, aber immer noch besser als wenn sich das Programm für mehrere Minuten selbst tot legt.
😉