Ein Softwaresystem nachträglich multithread-tauglich machen zu müssen ist kein Spass. Ganz besonders dann nicht, wenn die synchronized Blöcke entfernt werden müssen - sie blockierten die zentralen, langlaufenden Methoden (10-200 Millisekunden). Zum Glück gab es bereits sehr viele Unit-Tests. Dadurch konnte zumindest geprüft werden, ob das Refactoring stabil war. War es ![]()
Zum Testen der Threadsicherheit wurden drei zusätzliche Tests geschrieben. Diese bauen die zentrale Struktur auf und erzeugen jeweils 20.000 Threads. Diese 20.000 Threads beschiessen dann das System in den zwei entscheidenen Methoden. Die Methoden werden pro Thread mehrfach und auch gemischt aufgerufen. Zwischen den Aufrufen wird eine Pause von 0-400 Millisekunden eingelegt. Getestet wurde auf einer Maschine mit 2 Prozessoren und Hyperthreading. Die Tests wurden 10 mal wiederholt. Dabei schlug kein Test fehl. Ich vermute jetzt, dass die Operation Threadsicherheit gelungen ist.
Trotzdem bleibt die Unsicherheit. Wie verhält sich das System im Einsatz. Das sehen wir dann in den nächsten Tagen ![]()
