PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : *printf-Pufferung und Thread Safety?



Deever
03-04-2005, 10:33
Hey Amigos, wie geht's?

Ausgabefunktionen wie printf() allozieren je nach eingestellter Pufferung einen Puffer, der ja über einen static deklarierten Pointer referenziert werden muß, damit die Funktion den Puffer nach einem wiederholten Aufruf wieder finden kann. Meine Frage: Sinde diese Funktionen jetzt deshalb überhaupt noch threadsafe und wenn ja, wie?

Vielen Dank für eure Antworten!
Gruß,
/dev

locus vivendi
03-04-2005, 16:35
Ausgabefunktionen wie printf() allozieren je nach eingestellter Pufferung einen Puffer, der ja über einen static deklarierten Pointer referenziert werden muß, damit die Funktion den Puffer nach einem wiederholten Aufruf wieder finden kann.
Kannst du das näher erläutern?


Meine Frage: Sinde diese Funktionen jetzt deshalb überhaupt noch threadsafe und wenn ja, wie?
Die Verwendung eines solchen Puffers wäre ein deutlicher Hinweis das diese Funktionen nicht threadsafe sind. Aber Gewissheit kann dir nur die Dokumentation der Implementierung geben. (bzw. die Implementierung selber)

Zu der Frage wie es möglich ist, das eine Funktion threadsafe ist, obwohl ein statischer Puffer verwendet wird: Vorstellen könnte man sich z.B., daß die Funktion ihre eigene Ausführung serialisiert. Es gibt sicher noch mehr Möglichkeiten. Allerdings glaube ich nicht, daß es in der Praxis Sinn macht, erst einen statischen Puffer zu verwenden, und dann um das Problem herumzuarbeiten.

RHBaum
04-04-2005, 11:06
Ich glaub er meint die internen puffer die cout / std::cout verwenden ....

Die puffer sollten schon threadsicher sein, sonst wuerde es ja deine STL / libc implementation stark einschraenken ... Also die C-Version isses definitiv (kenne keine wo es nich iss ) , und selbst bei der STL wirst kaum eine Implementation finden, wo es nicht so ist !

die libs koennen die puffer selber mittels nen mutex locken, und tun das natuerlich auch ....

die frage iss nur, auf welcher ebene sie locken ....
Kannst ja mal testweisse 100 threads aufmachen die alle parralel zueinander 1024 zeichen auf cout schiessen. Villeicht hasst ja gleuck und die kommen im stueck an :D Im schlimmsten fall sinds halt zerstueckelt ...
Aber es darf definitv kein fehler und kein undefiniertes programmverhalten geben ....

ciao ...

locus vivendi
04-04-2005, 13:24
Ich glaub er meint die internen puffer die cout / std::cout verwenden ....
Er schrieb ja "static deklariert". Und ich glaube jetzt nicht das die verbreiteten Implementierungen damit Arbeiten.


Aber es darf definitv kein fehler und kein undefiniertes programmverhalten geben ....
Das sollte es nicht, aber so allgemein eine Garantie gibt es denke ich nicht.

RHBaum
05-04-2005, 10:24
wie genau cout / std::cout deklariert sind, hängt von der Impl ab ... zumindest sind sie mindestens global erreichbar ... was die frage nach der threadsicherheit prinzipiell berechtigt ....


Das sollte es nicht, aber so allgemein eine Garantie gibt es denke ich nicht.
Doch, denk schon das es das gibt.
Stell dir vor dein puffer fuer die consolen ausgabe (cout) waer nich threadsicher, dann muesste in jeder impl wo das so so ist, und man mt verwendet, muesste man fuer die verwendung von printf etc ... einen globalen mutex anlegen ... und das hab ich noch nie gesehen ....

Oder gibt es compiler / entwicklungsumgebungen die expliziet als nicht mt faehig ausgewiesen sind ?

M$ machts so, das sie fuer MT extra c-libs zur verfuegung stellen ... also die fuer single thread ohne sicher ohne mutex arbeitet und damit etwas schneller ....

Weiss nich wie es der gcc macht ..... oder ob der nur eine variante(mt) hat

ciao ...

locus vivendi
06-04-2005, 11:42
Ich glaube man kann da zwei Standpunkte einnehmen. Der Erste ist, daß man weil der C++-Standard keine Aussagen über Multi-Threading macht, davon ausgeht das es überhaupt keine Garantien diesbezüglich gibt (natürlich kann die konkrete C++-Implementierung Garantien geben).

Der Zweite ist, man sagt sich, weil die Implementierung Multi-Threading vorsieht muss sie auch gleichzeitig Garantien geben das ihre Teile threadsafe(*) sind.

Ich tendiere eher zum Ersten. Dieser scheint mir zumindest im Einklang mit der von mir verwendeten Implementierung zu sein. Falls du das Dokument nicht schon kennst, hier mal ein Link zu einem relevanten FAQ-Eintrag der GNU libstdc++:
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#3

*: "threadsafe" scheint mir ein unscharfer Begriff zu sein, ich gehe mal auf gut Glück davon aus, daß wir ähnliche Bedeutungen im Hinterkopf haben.

Deever
06-04-2005, 14:00
Vielen Dank für eure Antworten!

Ich muß mich schon entschuldigen, denn offensichtlich habe ich nicht klar genug erwähnt, daß ich mich auf die libc bezog.

Ich werd mir den Quellcode mal ansehen, sobald ich die Zeit dazu habe!

Gruß,
/dev