ist sprintf threadsicher?

Sie haben mehrere Probleme mit Ihrem Code.

1. Ihre Verwendung von snprintf ist sehr verdächtig. Benutze es nicht nur um Kopiere einen String. Übergeben Sie im Allgemeinen dynamisch zugewiesene Zeichenfolgen nicht mit welchem ​​Inhalt auch immer als Format für eine der printf -Funktionen. Sie interpretieren den Inhalt und wenn es etwas in ihnen gibt ähnelt einem% -Format, du bist verloren.
2. Verwenden Sie static buffers nicht wie Sie. Dies ist sicherlich auch nicht Thread Safe nicht Wiedereintritt.
3. Entweder printf direkt mit einem geeigneten Format verwenden oder ersetzen der Aufruf von puts .

Linux hält sich dann an den POSIX-Standard, der erfordert, dass die Standard-IO-Funktionen Thread-sicher sind.

Ihre Frage hat eine falsche Prämisse. Auch wenn sprintf selbst sicher von mehreren Threads gleichzeitig aufgerufen werden kann (wie ich es hoffe), schützt Ihr Code Ihre globale Variable nicht. Die Standardbibliothek kann Ihnen dort möglicherweise nicht helfen.

In Bezug auf Ihr Update ist es nicht beunruhigend, wenn der logBuffer Inhalt verstümmelt wird:

Ich bin mir nicht sicher, warum Sie vermeiden möchten, dass Ihre Funktion vollständig threadsicher ist, indem Sie einen lokal zugewiesenen Puffer oder einen Synchronisationsmechanismus verwenden, aber wenn Sie wissen wollen, was POSIX darüber zu sagen hat, gehen Sie ( Ссылка ):

  

Die Anwendungen müssen sicherstellen, dass der Zugriff auf jeden Speicherort durch mehr als einen Steuerungsstrang (Threads oder Prozesse) eingeschränkt ist, so dass kein Steuerungsstrang einen Speicherort lesen oder ändern kann, während ein anderer Steuerungsstrang diesen ändert. Ein solcher Zugriff wird durch die Verwendung von Funktionen eingeschränkt, die die Thread-Ausführung synchronisieren und auch den Speicher in Bezug auf andere Threads synchronisieren. [gefolgt von einer Liste von Funktionen, die Synchronisation bereitstellen]

So sagt POSIX, dass Ihr Programm sicherstellen muss, dass mehrere Threads logBuffer nicht gleichzeitig ändern (oder logBuffer in einem Thread ändern, während sie es in einem anderen Thread lesen). Wenn Sie sich nicht daran halten, gibt es kein Versprechen, dass das schlimmste, was passieren wird, verzerrte Daten in logBuffer sind. Es gibt einfach kein Versprechen, was die Ergebnisse sein werden. Ich weiß nicht, ob Linux ein spezifischeres Verhalten dokumentieren könnte, aber ich bezweifle es.

"Es gibt kein Problem mit snprintf() in mehreren Threads."

Nicht wahr.

Nicht wahr, zumindest bei POSIX-Funktionen.

Alle standardmäßigen vararg -Funktionen sind nicht mt-sicher - dies beinhaltet alle printf() -Familien (1), aber auch alle anderen variadic -Funktionen (2)

1. sprintf() ist zum Beispiel: "MT-Safe locale | AS-Unsafe-Heap | AC-Unsafe mem" - was bedeutet, dass es fehlschlagen kann, wenn das Gebietsschema asynchron gesetzt wird oder wenn eine asynchrone Löschung von Threads verwendet wird . Mit anderen Worten, bei der Verwendung solcher Funktionen in einer MT-Umgebung muss besondere Aufmerksamkeit geschenkt werden.

2. va_arg ist nicht mt-safe: | MT-Sicheres Rennen: ap | AS-Safe | AC-Unsafe korrupt | - was bedeutet, dass Inter-Verriegelung erforderlich ist.

Zusätzlich, was offensichtlich sein sollte, kann sogar die mt-safe-Funktion auf unsichere Weise verwendet werden - was zum Beispiel passiert, wenn zwei oder mehr Threads dieselben Daten / Speicherbereiche betreiben.

Es ist nicht threadsicher, da der Puffer, in dem Sie sprintf verwenden, von allen Threads gemeinsam genutzt wird.

"Haben Sie eine Referenz, die besagt, dass sie nicht Thread-sicher sind? Wenn ich Google, scheint es, dass sie sind"

Meine vorherige Antwort auf diese Frage wurde entfernt / gelöscht (warum?), also versuche ich es erneut, indem ich einen anderen Ansatz verwende:

1. AC (async. Aufhebung von Threads): Dies ist offensichtlich ein Fall, in dem fast der gesamte "scheinbar MT-sichere" Code versagen kann, einfach weil der Thread zu einem zufälligen Zeitpunkt unterbrochen wird, also keine Es wird garantiert, dass die Synchronisationsmethoden korrekt funktionieren (dh jede Form von Mutex kann nicht wirklich garantiert werden, um korrekt zu funktionieren)

2. Threads können die gleiche malloc () -Arena verwenden, was bedeutet, dass wenn einer der Threads fehlschlägt (dh es wird die Malloc-Arena beschädigen), alle aufeinander folgenden Aufrufe von malloc () dazu führen Kritische Fehler - das hängt natürlich von der Systemkonfiguration ab - bedeutet aber auch, dass niemand davon ausgehen sollte, dass fehlerhafte (De-) Zuweisungen sicher sind.

Da alle Systeme die Möglichkeit bieten, verschiedene lokale Einstellungen zu verwenden, ist es offensichtlich, dass async. Änderungen an den "Gebietsschema" -Einstellungen können zu Fehlern führen ...

Grüße.