FloatToStr nicht Thread-sicher aber erweiterte Form?

[Mikkey]

Was bedeutet die Aussage der Online-Hilfe?

Zitat:

Die erste Form von FloatToStrF ist nicht Thread-sicher

Inwieweit ist die zweite (erweiterte) Form der ~ToStr-Funktionen in einer Multithreading-Umgebung threadsicher, kann ich dieselbe TFormatSettings-Variable parallel in verschiedenen Threads verwenden?

Ihr könnt davon ausgehen, dass ich die Suchfunktion bereits zum glühen gebracht habe, aber dazu gibt es keine Aussage.

Es geht konkret um ein Projekt, in dem durchweg ein Punkt als Dezimaltrenner verwendet werden muss. Bisher sind DIE FormatSettings Bestandteil eines Objekts, das praktisch allen Programmteilen bekannt ist und eine Funktion zum Abruf dieser Struktur besitzt.
Kann die Funktion nun einen Zeiger auf die Formatsettings zurückgeben, muss der Inhalt zurückgegeben werden oder muss jeder Thread eine neue Struktur erzeugen?

Vielen Dank im Voraus

PS: Es ist ein C++-Projekt, aber da dürften ggü. Delphi keine Unterschiede bestehen.

[mkinzler]

Daten sollten nicht unsychronsiert zwischen Thraeds geteilt werden.

[Popov]

Zitat:

Zitat von Mikkey (Beitrag 1306400)

Was bedeutet die Aussage der Online-Hilfe?

Das bedeutet, dass dir

Delphi-Quellcode:

FloatToStr

u. U. um die Ohren fliegen kann, weil irgendwer für den Preis 3,95 Euro in das Feld 3,95 eingibt (mit Komma), im System aber als Dezimaltrennzeichen ein Punkt (.) eingetragen ist und dein Programm deshalb ein 3.95 erwarten (mit Punkt).

Das

Delphi-Quellcode:

FloatToStr

richtet sich immer nach dem im System eingetragenem Dezimaltrennzeichen, was an für sich keine schlechte Idee ist. Das kann aber gelegentlich zu Problemen führen. Hier bist also nicht du der Herr über das Dezimaltrennzeichen in deinem Programm, sondern das System.

Wieso man das nun mit Thread-Sicherheit beschreibt fällt mir nicht ein. Gemeint ist aber damit, dass es u. U. zu Fehlermeldungen kommt wenn ein falsches Zeichen eingegeben wird. Mit der zweiten Form kann man nämlich

Delphi-Quellcode:

FloatToStr

mitteilen welches Dezimaltrennzeichen er beachten soll. Ein Beispiel:

Delphi-Quellcode:

var
  fs: TFormatSettings;
  s: string;
begin
  fs.DecimalSeparator := ','; //falls Komme erwünscht
  s := FloatToStr(3.95, fs);
  ShowMessage(s);
end;

[Der schöne Günther]

Zitat:

Zitat von Popov (Beitrag 1306412)

Wieso man das nun mit Thread-Sicherheit beschreibt fällt mir nicht ein.

Naja, angenommen du gewöhnst dir einfach an, immer am globalen Decimal-Separator herumzuspielen wenn du es grade brauchst dann bekommst du ein Problem wenn du anfängst mit mehreren Threads zu arbeiten.

Die Hilfe erzählt manchmal gerne :-)
Das beste ist, wo sie irgendwo zu Methoden eines TDataSets anfangen zu erklären, was eigentlich virtuelle Methoden sind. Wenn man ja schon dabei ist... :-D

[Sir Rufo]

Alle Funktionen, die z.B. mit den

Delphi-Quellcode:

FormatSettings

arbeiten sind nicht threadsafe, denn der interne Aufruf sieht so aus:

Delphi-Quellcode:

function FloatToStr(Value: Extended): string;
begin
  Result := FloatToStr(Value, FormatSettings); // GLOBALE Variable FormatSettings wird benutzt
end;

Und eine globale Variable ist nun mal nicht threadsafe (es gibt da Ausnahmen, aber die wollen wir mal aussen vor lassen), denn in diese kann man jederzeit von überall einfach reingreifen und verändern.

Korrekt wäre es einem Thread eine eigene

Delphi-Quellcode:

FormatSettings

Variable zu verpassen, die dann innerhalb des Threads verwendet wird.

[Mikkey]

Zitat:

Zitat von Popov (Beitrag 1306412)

Das bedeutet, dass dir

Delphi-Quellcode:

FloatToStr

u. U. um die Ohren fliegen kann

Ich habe mit Absicht nach

Delphi-Quellcode:

FloatToStr

gefragt, nicht nach

Delphi-Quellcode:

StrToFloat

. Ersteres fliegt einem in der Regel nicht um die Ohren.

Zitat:

Zitat von Popov (Beitrag 1306412)

Wieso man das nun mit Thread-Sicherheit beschreibt fällt mir nicht ein

Genau darum dreht sich aber die Frage, kann man sich auf die Umkehrung der OH-Aussage verlassen?

@mkinzler:
Üblicherweise können Daten, die nur gelesen werden, ohne Weiteres zwischen verschiedenen Threads geteilt werden.

@Günther:
Das macht Sinn, müsste dann aber auch den Schluss zulassen, dass ich mit einer einzelen FormatSettings-Struktur auch in mehreren Threads arbeiten kann?

[Sir Rufo]

Das Hauptproblem ist doch, dass man die Zugriffe auf eine gemeinsame Struktur nicht kontrollieren kann. Man muss im gesamten Programm höllisch aufpassen, da nicht irgendwie reinzugrätschen um dadurch die lustigsten Fehler zu erhalten: "Geht meistens, aber nicht kurz nach Sonnenuntergang!"

Das ist das Salz in der Suppe beim Multi-Threading!

[BUG]

Zitat:

Zitat von Mikkey (Beitrag 1306428)

Üblicherweise können Daten, die nur gelesen werden, ohne Weiteres zwischen verschiedenen Threads geteilt werden.

Man kann sich noch darüber streiten, ob das Starten eines Threads eine Synchronisation ist :stupid:

Zitat:

Zitat von Sir Rufo (Beitrag 1306430)

Das ist das Salz in der Suppe beim Multi-Threading!

Und Speichersemantik sind die Speckgrieben.

[himitsu]

Zitat:

nicht threadsicher

Ohne den Settings-Parameter gehen diese Funktionen auf die globale FormatSettings-Variable
und was ein nicht abgesicherter Zugriff auf globale Variablen bedeutet, daß verstehst du doch?
Vorallem wenn während dessen irgendwer diese Variable mal wieder bösartig verändern könnte.

[Mikkey]

Es geht mir nicht darum, dass ich die globale Variable verwenden möchte, sondern darum, ob der Umkehrschluss, dass bei einer eigenen Variablen, die von allen Threads lesend(!) verwendet wird, Probleme auftreten können. Fall ja: Reicht eine flache Kopie der Struktur oder muss sie komplett neu erzeugt werden.

Als Hinweis:
Die vereinfachten Methoden

Delphi-Quellcode:

FloatToStr

etc. sind in C++ eh nicht verwendbar, weil die globalen Variablen

Delphi-Quellcode:

DecimalSeparator

etc. nicht verfügbar sind und auch über

Delphi-Quellcode:

TFormatSettings::DecimalSeparator

nicht ansprechbar.