Zitat von s.h.a.r.k:

Ich habe gerade einen Konstruktor geschrieben, der die Format-Methode nutzt. Ich weiß ja pauschal nicht, ob diese Methode threadsafe ist oder nicht.

1. hat das gar nichts mit dem Konstruktor zu tun, sondern gilt für jeden Aufruf von Format aus verschiedenen Threads.

2. nimmt man deswegen immer die threadsichere Variante von Format, bei der man die FormatSettings mit angibt. Es ist nämlich nicht der Code von Format, der nicht threadsicher ist, sondern die Verwendung der globalen FormatSettings.

Zitat von Uwe Raabe:

Zitat von s.h.a.r.k:

Ich habe gerade einen Konstruktor geschrieben, der die Format-Methode nutzt. Ich weiß ja pauschal nicht, ob diese Methode threadsafe ist oder nicht.

1. hat das gar nichts mit dem Konstruktor zu tun, sondern gilt für jeden Aufruf von Format aus verschiedenen Threads.

2. nimmt man deswegen immer die threadsichere Variante von Format, bei der man die FormatSettings mit angibt. Es ist nämlich nicht der Code von Format, der nicht threadsicher ist, sondern die Verwendung der globalen FormatSettings.

Ich habe diese Format-Methode leider nicht bis ins letzte Details ergründet, da dort auch irgendwann mal mit Assembler hantiert wird. Aber danke für den Hinweis. Habe gerade auch den Quellcode-Kommentar von TFormatSettings gelesen. Irgendwie muss man bei Threads viel zu viel beachten

Zitat von chaosben:

5.: Das dürfte wirkungslos sein, da die CriticalSection scheinbar pro Objekt existiert. So würde zwar jeder Thread das Lock setzen, aber kein anderer würde sich daran stören.

PS: Mir scheint das Problem besteht bei allen anderen Beispielen auch.

Stimmt... D.h. ich muss mir somit für dies Format-Methode einen threadsicheren Wrapper basteln, oder wie Uwe Raabe vorgeschlagen hat, die Format-Methode immer mit dem FormatSettings-Parameter aufrufen.

Zitat von chaosben:

PPS: Bei einem zeitkritischen Projekt habe ich mal festgestellt, das TCriticalSection entschieden langsamer war, als RTL_CRITICAL_SECTION. Warum konnte ich leider nicht ergründen

Dank für die Info. Interessant wäre jetzt noch zu wissen, wie hoch der Geschwindigkeitsgewinn denn gewesen ist?

Tschaa ... jetzt wolle ich ne kleine Demoapp schreiben (bezüglich der Zeit) und da taucht das Problem nicht mehr auf.
Mal sehen, vielleicht finde ich die alten Sourcen noch mal.

Zitat von chaosben:

5.: Das dürfte wirkungslos sein, da die CriticalSection scheinbar pro Objekt existiert. So würde zwar jeder Thread das Lock setzen, aber kein anderer würde sich daran stören.

Die könnte man als class var speichern und dafür im class contructor initialisieren und im class destructor wieder freigeben.

Zitat von chaosben:

Tschaa ... jetzt wolle ich ne kleine Demoapp schreiben (bezüglich der Zeit) und da taucht das Problem nicht mehr auf.
Mal sehen, vielleicht finde ich die alten Sourcen noch mal.

TCriticalSection ist eigentlich nur ein Wrapper für eine RTL_CRITICAL_SECTION, ergo wird das wohl gleich schnell sein. Muss daher wohl am Projekt selbst gelegen haben.

Zitat von jaenicke:

Zitat von chaosben:

5.: Das dürfte wirkungslos sein, da die CriticalSection scheinbar pro Objekt existiert. So würde zwar jeder Thread das Lock setzen, aber kein anderer würde sich daran stören.

Die könnte man als class var speichern und dafür im class contructor initialisieren und im class destructor wieder freigeben.

Jup, das ist klar. Aber bevor ich da jeder Klasse eine extra CriticalSection mitgebe, schreibe ich mir da dann doch liebe einmal eine threadsichere Methode, die das Format eben entsprechend kapselt