Kurze Antwort: Ja, ab C11, der ersten Version des C-Standards, die das Konzept von Threads enthält, müssen mallocFreunde threadsicher sein. Viele Betriebssysteme, die beide Threads und eine C-Laufzeit enthielten, haben diese Garantie lange vor dem C-Standard gegeben, aber ich bin nicht bereit, allen zu schwören . Allerdings mallocund Freunde sind nicht und nie aufgefordert wurden , einspringende zu sein.
Das heißt, es ist sicher, mehrere Threads gleichzeitig aufzurufen mallocund zu verwenden, freeohne sich Gedanken über das Sperren zu machen, solange Sie keine der anderen Regeln für die Speicherzuweisung verletzen (z. B. freeeinmal und nur einmal für jeden von zurückgegebenen Zeiger aufrufen malloc). Es ist jedoch nicht sicher, diese Funktionen von einem Signalhandler aus aufzurufen, der möglicherweise einen Aufruf an mallocoder freein dem Thread, der das Signal verarbeitet, unterbrochen hat . Wenn Sie Funktionen verwenden, die über ISO C hinausgehen, können Sie manchmal sicherstellen, dass der Thread, der das Signal verarbeitet, einen Aufruf von mallocoder free, z. B. mit sigprocmaskund sigpause, nicht unterbrochen hat. Versuchen Sie dies jedoch nicht, es sei denn, Sie haben keine andere Option, da es schwierig ist, die richtigen Ergebnisse zu erzielen.
Lange Antwort mit Zitaten: Der C-Standard hat in der Überarbeitung von 2011 ein Thread-Konzept hinzugefügt (Link führt zum Dokument N1570, das dem offiziellen Text des 2011-Standards, der kostenlos öffentlich verfügbar ist, am nächsten kommt). In dieser Überarbeitung heißt es in Abschnitt 7.1.4 Absatz 5 :
Sofern in den folgenden detaillierten Beschreibungen nicht ausdrücklich anders angegeben, verhindern Bibliotheksfunktionen Datenrennen wie folgt: Eine Bibliotheksfunktion darf nicht direkt oder indirekt auf Objekte zugreifen, auf die andere Threads als der aktuelle Thread zugreifen, es sei denn, auf die Objekte wird direkt oder indirekt über die Argumente der Funktion zugegriffen . Eine Bibliotheksfunktion darf keine Objekte direkt oder indirekt ändern, auf die andere Threads als der aktuelle Thread zugreifen können, es sei denn, auf die Objekte wird direkt oder indirekt über die nicht konstanten Argumente der Funktion zugegriffen. Implementierungen können ihre eigenen internen Objekte zwischen Threads gemeinsam nutzen, wenn die Objekte für Benutzer nicht sichtbar und vor Datenrennen geschützt sind.
[Fußnote: Dies bedeutet beispielsweise, dass eine Implementierung ein statisches Objekt ohne Synchronisierung nicht für interne Zwecke verwenden darf, da dies selbst in Programmen, die Objekte nicht explizit zwischen Threads gemeinsam nutzen, zu einem Datenrennen führen kann. Ebenso ist es einer Implementierung von memcpy nicht gestattet, Bytes über die angegebene Länge des Zielobjekts hinaus zu kopieren und dann die ursprünglichen Werte wiederherzustellen, da dies zu einem Datenrennen führen kann, wenn das Programm diese Bytes zwischen Threads teilt.]
Soweit ich weiß, ist dies eine langwierige Art zu sagen, dass die durch den C-Standard definierten Bibliotheksfunktionen threadsicher sein müssen (im üblichen Sinne: Sie können sie von mehreren Threads gleichzeitig aufrufen, ohne sich selbst zu sperren , solange sie nicht mit den als Argumente übergebenen Daten in Konflikt geraten), es sei denn, die Dokumentation für eine bestimmte Funktion besagt ausdrücklich, dass dies nicht der Fall ist.
Dann bestätigt 7.22.3p2 , dass malloc, calloc, realloc, align_alloc und insbesondere free threadsicher sind:
Um die Existenz eines Datenrennens zu bestimmen, verhalten sich Speicherzuweisungsfunktionen so, als hätten sie nur auf Speicherorte zugegriffen, auf die über ihre Argumente zugegriffen werden kann, und nicht auf andere Speicher mit statischer Dauer. Diese Funktionen können jedoch den von ihnen zugewiesenen oder freigegebenen Speicher sichtbar ändern. Ein Aufruf zum Freigeben oder Neuzuweisen, der die Zuweisung einer Region p des Speichers aufhebt, wird mit jedem Zuweisungsaufruf synchronisiert, der die Region p ganz oder teilweise zuweist. Diese Synchronisation erfolgt nach jedem Zugriff von p durch die Freigabefunktion und vor einem solchen Zugriff durch die Zuweisungsfunktion.
Kontrast , was es sagt über strtok, was nicht und nie ist gewesen Thread-sicher, in 7.24.5.8p6 :
Die strtok-Funktion ist nicht erforderlich, um Datenrennen mit anderen Aufrufen der strtok-Funktion zu vermeiden.
[Fußnote: Die Funktion strtok_s kann stattdessen verwendet werden, um Datenrennen zu vermeiden.]
(Kommentar zur Fußnote: nicht verwenden strtok_s, verwenden strsep.)
Ältere Versionen des C-Standards sagten überhaupt nichts über die Gewindesicherheit aus. Aber sie tat sagt etwas über reentrancy, weil Signale immer einen Teil des C Standard. Und dies ist, was sie sagten und auf den ursprünglichen ANSI C-Standard von 1989 zurückgingen (dieses Dokument hat einen nahezu identischen Wortlaut, unterscheidet sich jedoch stark von der Abschnittsnummerierung des ISO C-Standards, der im folgenden Jahr herauskam):
Wenn ein [a] -Signal nicht als Ergebnis des Aufrufs der Abbruch- oder Erhöhungsfunktion auftritt, ist das Verhalten undefiniert, wenn der Signalhandler eine andere Funktion in der Standardbibliothek als die Signalfunktion selbst aufruft oder auf ein Objekt mit einer anderen statischen Speicherdauer verweist als durch Zuweisen eines Werts zu einer statischen Speicherdauervariablen vom Typ flüchtig sig_atomic_t. Wenn ein solcher Aufruf der Signalfunktion zu einer SIG_ERR-Rückgabe führt, ist der Wert von errno unbestimmt.
Das ist eine langatmige Art zu sagen , dass C - Bibliotheksfunktionen sind nicht einspringenden als allgemeine Regel sein , erforderlich. Ein sehr ähnlicher Wortlaut erscheint immer noch in C11, 7.14.1.1p5 :
Wenn ein [a] -Signal nicht als Ergebnis des Aufrufs der Abbruch- oder Erhöhungsfunktion auftritt, ist das Verhalten undefiniert, wenn der Signalhandler auf ein Objekt mit statischer oder Thread-Speicherdauer verweist, das kein sperrfreies atomares Objekt ist, außer durch Zuweisen Ein Wert für ein als flüchtig deklariertes Objekt sig_atomic_t oder der Signalhandler ruft eine andere Funktion in der Standardbibliothek als die Abbruchfunktion, die _Exit-Funktion, die quick_exit-Funktion oder die Signalfunktion auf, wobei das erste Argument der entsprechenden Signalnummer entspricht das Signal, das den Aufruf des Handlers verursacht hat. Wenn ein solcher Aufruf der Signalfunktion zu einer SIG_ERR-Rückgabe führt, ist der Wert von errno unbestimmt.
[Fußnote: Wenn ein Signal von einem asynchronen Signalhandler generiert wird, ist das Verhalten undefiniert.]
POSIX erfordert eine viel längere, aber im Vergleich zur Gesamtgröße der C-Bibliothek immer noch kurze Liste von Funktionen, die von einem "asynchronen Signalhandler" sicher aufgerufen werden können, und definiert auch detaillierter die Umstände, unter denen ein Signal "anders auftreten kann" als Ergebnis des Aufrufs der Abbruch- oder Erhöhungsfunktion. " Wenn Sie mit Signalen etwas nicht Triviales tun, schreiben Sie wahrscheinlich Code, der auf einem Betriebssystem mit Unix-Charakter ausgeführt werden soll (im Gegensatz zu Windows, MVS oder etwas Eingebettetem, das wahrscheinlich keine vollständig gehostete Implementierung von C in hat an erster Stelle), und Sie sollten sich mit den POSIX-Anforderungen für sie sowie den ISO C-Anforderungen vertraut machen.