4. Threadsicherheit

Threadsicherheit

  • T

    Hallo zusammen!

    Ich habe da mal eine Frage. Ich habe eine DLL die detaillierte Fehlermeldungen
    in einen globalen Buffer schreibt (char array). In der DLL wird auf diesen Buffer sowohl lesend als auch schreibend zugegriffen(sprintf, strcpy).
    Jetzt könnte es da ja natürlich Probeleme geben, wenn diese DLL in einer Multithreading-Anwendung verwendet wird. Desshalb werde ich das Abfragen dieser Meldung mit "GetLastErrMsg" in einer Multithreading-Anwendung verbieten.
    Trotzdem werden dann aber mehrere Threads ihre Fehlermeldungen in diesen Buffer schreiben und manchmal den Inhalt des Buffers temporär zwischenspeicher (also lesender zugriff). Jetzt habe ich etwas angst, dass mir die DLL vielleicht abstürzt, wenn mehrere threads diesen Zugriff machen. Eigentlich meine ich dürft nichts passieren, sollte bloß unsinniger Text rauskommen wenn mehrere threads gleichzeitig schreiben. Nun aber meine Frage:
    Weiß von euch jemand, ob es da zur Laufzeit Probleme geben könnte?

    Schreibend greife ich so zu: sprintf(ErrorMessage,"Neuer Fehler")
    und lesend so: strcpy(temporärerSpeicher, ErrorMessage)

    Gruß Tom

    0
  • R

    Warum sicherst du deine Dll ned ab ?

    nen mutex bevor du in den puffer reinschreibst ... und aufloesen wenn wieder rauskommst ....
    und zusaetzlich natuerlich auch nen mutex vor die Quelle, sonst kann dir nen thread den fehler umstellen bevor du den wert komplett draussen hast, im unguenstigsten falle ....

    dann sollt eigentlich nimmer viel passieren.

    wenn du wegen der performance bedenken hasst ... bau ne mt dll und ne normale ohne mutexe. Mit intelligenten Mutex-Objecten kann man ueber compilerdirektiven die dinger vom compiler in nichts aufloesen lassen ...

    Ciao ...

    0
  • M

    Da Du mit C-Strings arbeitest und damit auf die terminierenden 0-Bytes angewiesen bist, kann das Verhalten durchaus undefinierter als "nur Zeichenmüll" sein.

    Warum verriegelst Du die Schreib- und Lesezugriffe nicht einfach gegeneinander?

    Besser als dieser Blindflug ist das doch auf jeden Fall, und eine einfache CriticalSection in der DLL - parallel zu Deinem Speicher - wird das Problem lösen.

    0
  • T

    Ich habe die DLL schon vollgepflastert mit CriticalSections, desshalb wollte ich das vermeiden. Aber selbst wenn ich das ganze absichere ist es für Multithreading ja immer noch ungeeignet. Beispiel:

    Funktionsaufruf thread 1 (Fehler passiert)
    Thread wird unterbrochen
    Funktionsaufruf thraed 2 (Fehler passiert)
    Fehlerbehandlung thread 2
    ....
    Fehlerbehandlung thread 1 (Hat jetzt den Fehler, den Thread 1 verursacht hat)

    Und das kann ich ja nicht verhindern, das müsste der Anwender der DLL ja machen. Oder seh ich das falsch.

    0
  • S

    Du könntest die Messages auch per Thread abspeichern.
    (z.B. TLS benutzen.)

    0
  • M

    So ist der Ablauf ja nicht. Angenommen, der interne Speicher ist über eine Criticalsection gesichert.

    Dann sieht das so aus:

    Thread 1 Funktionsaufruf
critsection wird gelockt von Thread 1             Thread 2 Funktionsaufruf
einfügen der Daten in Speicher                    critsection wird angefordert
                                                  nicht verfügbar, Thread geht
                                                  in Wartezustand
critsection freigeben                             critsection wird gelockt
Funktionsaufruf Ende                              einfügen der Daten
                                                  critsection freigeben
                                                  Funktionsaufruf Ende

    Bei solchen Fragen erscheint mir die Lektüre von

    Windows Multithreading mit C++ und C# | ISBN: 3826609891

    angemessen, denn die Aussage "alles mit CritSections vollgepflastertet" klingt nicht vertrauenerweckend.

    0
  • C

    Dieser Thread wurde von Moderator/in Marc++us aus dem Forum C++ in das Forum WinAPI verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • T

    der Ablauf war ja auch bei fehlender Synchronisation gemeint.
    Mit Threads kenn ich mich eigentlich schon etwas aus. Es halt aber nicht so einfach eine alte DLL die aus über 40.000 Zeilen C-Code besteht und bei der der globale Namensraum sehr leichtfertig genutzt wurde plötzlich Threadsicher zu machen 😃

    0
  • S

    C-Code besteht und bei der der globale Namensraum

    C hat ja gar keine Namespaces... od. wenn Du so willst nur den globalen...

    0
  • T

    ich sagte doch: "globaler Namensraum". Es denke ich eine gängige Bezeichnung.
    Deine Idee mit TLS find ich aber super. Das kannte ich bisher noch nicht.
    Denke das löst das Problem.
    Thx

    0
Anmelden zum Antworten