Probleme mit Multi-Threading? Oder doch nicht?

[illuminator]

Hallo,

ich hoffe meine Frage passt hier am besten hin.

Ich hab vor einem Jahr für meine Firma begonnen eine Anwendung zu programmieren die im Prinzip nicht viel mehr als eine erweiterte Ablaufsteuerung darstellt und in der Lage ist viele Dinge parallel auszuführen und zu überwachen.
Das Ganze ist in Delphi 7 Prof programmiert, läuft unter Windows 2000 und benutzt dabei mehrere Thread-Klassendie jeweils von TThread abgeleitet sind. Außerdem nutzt jeder Thread über ADO ein MySQL-Datenbank(manche Threads teilen sich eine Connection). Seit 8 Monaten läuft das eigentlich Stöungsfrei.

Nun gib es seit Anfang des Monats einen neuen Kollegen, der sich aufgrund einer Überarbeitung und neuen Features die anstehen in den Quellcode und das Konzept einarbeiten sollte. Anfang der Woche haben wir einen kleinen sporadischen Bug, der erst kürzlich im Zusammenghang mit den Anforderungen für einen neuen Kunden auftrat, dazu genutzt um gemeinsam eben diesen zu suchen und dabei ihm den Quellcode ein wenig zeigen.

Er war daraufhin ziemlich entsetzt als er meinte er hätte die Ursache für den Bug gefunden.

Eine Konfigurations-Klasse die vono allen Threads benutzt wird. Die Klasse besteht eigentlich nur aus einem Haufen Pfadangabenstrings und Integers die alle beim Start des Programm über die Funktion ReadIni() der Klasse aus einem Inifiles eingelesen.
Es ist halt die globale Configurationsklasse für die Anwendung.
Nachdem das Ini gelesen wurde werden die Threads erstellt und nie wieder schreibend auf diese Klasse zugegriffen.
Deswegen habe ich mir da get/set-Funktionen mit critical-sections gespart und habe die Instanz der Klasse Global gemacht. Kann ja nichts passieren dabei, dachte ich.
>> http://www.microsoft.com/austria/msd...ltithread.mspx

Er aber behauptet das auch rein lesender Zugriff zwischen Threads mit Sperren versehen werden muss, das sonst das Ergbnis "undefiniert" sei. OT: "Das ist ein NT-Kernel, da liest man nicht direkt aus dem Speicher. Da kann sonstwas passieren. Vollkommen undefiniert". Warum hat das dann die letzten 8 Monate funktioniert?: "Glück"

Ich bin anderer Meinung wie ihr euch denken könnt.
Das war jetzt viel Text aber ich hoffe hier kann mir jemand ein paar weitere Quellen nennen die meine Meinung entweder belegen oder widerlegen.

Was ich jetz nicht genau weiß ist was eigentlich Delphi-intern passiert wenn man auf Public-Member von Klassen lesend zugreift. Ob da nicht doch irgendwo ein Schreibzugriff auf Speicher ist.

Der Bug (eine Datenbankabfrage die alle Threads machen gibt fälschlicherweise 0 Records zurück) hat damit meiner Meinung nach nichts zu tun sondern liegt an der miserablen ADO-API oder MySQL. Leider lässt er sich fast gar nicht reproduzieren, man muss schon glück haben.

[himitsu]

Eigentlich ist ein gleichzeiger, "rein" lesender Zugriff nicht schlimm ... jedenfalls konnte ich dahingehend noch keine Probleme entdecken.



Aber wenn du z.B. Strings (AnsiString) verwendest, dann wird auch beim Lesen scheibend darauf zugegriffen (der Refferenzzähler) und da die StringFunctionen im allgemeinen nicht threadsicher sind, ist der String es also auch nicht.

Außweg wäre ein statisches CharArray (Array[0..x] of Char), oder auch WideStrings (die haben keinen "nicht threadsicher" Refferenzzähler, womit jeder seine eigene Kopie bekäme)

Oder wenn es bei den Strings (was übrigens für alle dynamischen Arrays gilt, denn was anderes ist der AnsiString auch nicht) bleiben soll, dann halt jeden Aufruf locken (wobei man ja nicht immer mit sowas rießigem wie critical-sections zuschlagen muß).

Delphi-Quellcode:

Type TMyClass = Class(...
  Private
    IntLock: TByteLock;
    irgendwas: String;
  Public
    Function GetString: String;
    ...
  End;

Function TMyClass.GetString: String;
  Begin
    Lock(IntLock);
    Result := irgendwas;
    UniqueString(Result);  // den String vereinzeln, also 'ne eigene Kopie für den anderen Thread erstellen
    Unlock(IntLock);
  End;

Eigentlich müßte im Konstructor noch IntLock über IntLock:=False, oder per InitLock(IntLock) initialisiert werden, aber da Klassen immer mit 0 initialisiert werden, was einem False entspricht, ist es nicht unbedingt nötig.


Passend dazu die "Kleinste" Lockmethode von mir
(na ja, eigentlich is mein BitLock kleine, aber ByteLock is halt klein genug und schneller)

Delphi-Quellcode:

  Type TByteLock = Type ByteBool;  // 8-bit

  Procedure InitLock(Var B: TByteLock);
    Begin  B := TByteLock(False);  End;

  Procedure Lock(Var B: TByteLock);
    ASM
      PUSH    &B
      @Loop:
      MOV     ECX, DWORD PTR [ESP]
      MOV     DL, ByteBool(&True)
      MOV     AL, &False
      LOCK    CMPXCHG BYTE PTR [ECX], DL
      JZ      @Exit
      PUSH    3
      CALL    Sleep
      JMP     @Loop
      @Exit:
      POP     &B
    End;

  Procedure Unlock(Var B: TByteLock);
    ASM
      //LOCK  MOV BYTE PTR [&B], &False  /// External Exception C000001E
      LOCK    AND BYTE PTR [&B], 0       ///
    End;

[illuminator]

Also ich hab noch ein wenig geforscht. Auch nach dem Referenzzähler den du erwähntest.

Alle Quellen die ich bisher auftreiben konnte behaupten, dass der Referenzzähler in der string-klasse seit Version 7 spätestens Thread-safe ist.
Schreibzugriff ist natürlich wieder eine andere Sache. D.h. Lesezugriff allein sollte wirklich unproblematisch sein.

Andere Frage dazu. Was ist eigentlich das schlimmste das passieren kann, wenn ich z.B. eine integer mit mehreren Threads lese und schreiben lasse (ohne critical sections)? Es gibt hierbei doch keine Exception oder ähnliches sondern lediglich flasche Ergebnisse bzw. irgendwelche Inhalte die nicht dem Erwarteten entsprechen oder?