Wenn man unter Delphi mit Threads arbeitet, dann darf man ja nicht so ohne weiteres auf die VCL zugreifen.
Aber wie sieht das denn aus mit Zugriffen auf Methoden in den System Libs? Gibt es denn da keine Zugriffsprobleme?

Man könnte auch anderes fragen: Wenn ich in einer Unit eine Procedure schreibe, die intern mit Variablen arbeitet, ggf. sogar andere Proceduren oder Funktionen aufruft aus anderen Units, ist dass denn Threadsafe?

Bitte nicht Antworten, wenn diese die Worte "glauben", "denken" oder "meinen" enthält.
Fakten und Wissen ist gefragt , denn es nützt mir nichts nur zu glauben dass mein Programm funktioniert

Hallo und in der Entwickler-Ecke!

Das Problem sind nicht so sehr die Funktionen oder Methoden, sondern der gleichzeitige Zugriff auf Daten. Das ist es (grob vereinfacht), weswegen das mit der VCL Probleme macht: Wenn zwei Threads gleichzeitig an einem Fenster Änderungen vornehmen wollen, dann geht halt schnell was kaputt.

Pauschal kann man das nicht beantworten - es kommt immer darauf an, was die Funktionen machen. Generell ist es kein Problem, Funktionen aus anderen Units parallel aufzurufen. Knifflig wird es erst, wenn diese auf denselben Daten arbeiten. Das kann auch versteckt sein durch Zugriff auf globale Variablen o.ä.

Im Zweifel daher immer etwas mehr absichern als zu wenig.

Bedeutet dann, dass ich in einem Thread keine Aufrufe in eine Delphi System Unit durchführen darf ohne Gefahr zu laufen einen Zugriffskonflikt oder Rechenfehler zu verursachen?

Ok, dann muss man alle Methoden, die von Threads verwendet werden sollen in einer Klasse kapseln und dann für jeden Thread eine Instanz davon erzeugen um sicher zu sein, dass es dann nicht zu Zugriffskonflikten kommen kann, wenn auf keine globalen Variablen zugegriffen wird (diese müssten an die Instanz übergeben werden)?
Meines Wissens nach ist es aber so, dass nur Variablen einer Klasse je Instanz unterschiedlich sind, der Code selbst aber für alle Instanzen identisch ist. Wenn jetzt eine Methode einer Klasse eine Variable definiert, ist die dann trotzdem Threadsafe, oder muss man diese dann auch als Variable innerhalb der Klasse definieren?

Ich habe keinen Überblick darüber, was in den Units, die du meinst, alles enthalten ist. Generell spricht nichts dagegen, die Funtkionen daraus in mehreren Threads zu verwenden. System.SysUtils.StringReplace ist z.B. gar kein Problem, solange du das nicht von zwei Threads aus auf dem selben String probierst. Bei System.SysUtils.FormatDateTime muss man dann aber schon aufpassen: Wenn man da die Variante ohne AFormatSettings als Parameter nimmt, wird auf globale Variablen zurückgegriffen - und das ist dann nicht Thread-sicher. Dabei ist es dann auch egal, ob du den Aufruf in einer Klasse kapselst oder nicht.

Also, es bleibt dabei: Eine pauschale Aussage "Funktionen aus Unit X sind (bzw. sind nicht) Thread-sicher" kann man nicht machen.

Vielleicht beschreibst du mal ein wenig, was du vorhast, dann kann man ggf. spezifischer helfen.

Die RTL ist nicht threadsafe. Allgemein kann man daher nicht sagen, dass alles klappt.

In den meisten Fällen genügt es aber, wenn der eigene Zugriff threadsicher ist. Anders sieht es z.B. bei Datenbankgeschichten aus. Da muss man genau schauen was da passiert und was unterstützt wird. Außerdem gibt es globale Geschichten, die schon angesprochen wurden, die Probleme machen können. Aber da die meistens nur gelesen werden, gibt es damit auch nicht unbedingt Probleme.

Beispiel:
TList selbst ist nicht threadsicher. Aber wenn man dafür sorgt, dass die Zugriffe darauf nicht parallel erfolgen können, sondern immer nur ein Thread gleichzeitig darauf zugreift, ist das kein Problem.

Wie man es selbst kapselt, spielt keine Rolle, ob in einer Klasse oder in mehreren einzelnen Funktionen.

Generell muss man aber sagen, dass man immer im Einzelfall prüfen muss.

Ok, wenn ich SysUtils.StringReplace aus mehreren Threads gleichzeitig aufrufen kann, dann ist meine Frage geklärt.
Denn darin werden Variablen definiert, die dann ja je Thread in einem anderen Speicherbereich liegen müssen, da sie ja in der Methode gelesen und geschrieben werden.
Danke.