Theards mit Rückgabe

[drakon]

Blue-Tiger schrieb:

drakon schrieb:

Solange nur jemand schreiben darf und die restlichen lediglich lesen, dann ist das auch kein Problem. Die Probleme kommen, sobald 2 Thredas auf etwas schreiben müssen.

meeeeep! Falsch!
Es kann auch dann zu Problemen kommen, wenn nur einer liest & einer schreibt. Siehe z. B. Producer-Consumer Probleme! Ausnahme: denn du kannst garantierten dass Read- & Wite-Operationen atomar sind und die Chaches zu jeder Zeit synchronisiert sind. Aber in der Regel kannst du das nicht.

Das hier wäre aber nicht wirklich ein Fall von typischem Producer-Consumer, denn es wird ja nichts aus einem Buffer genommen, sondern lediglich gelesen, was an dieser Stelle steht und nichts entfernt. Was das ist hat gar keinen Einfluss.
Das einzige, was da ja Probleme bereiten könnte, was ich mir vorstellen kann und du wahrscheinlich meinst, wenn ich dich richtig verstanden habe ist, wenn während dem Lesen der Thread unterbrochen wird, was dann natürlich auch blöde enden könnte, verstehe ich dich richtig?

[thread]

Was ist ein theard??

[franz]

thread schrieb:

Was ist ein theard??

Ein Thread (gemeinhin als "Fred" bekannt) ist ein Thema in einem Forum.
Der erste Post (= Eintrag) kommt vom TO ("Theo" = Thread Opener). Meistens folgen viele Posts von vielen verschiedenen Menschen die sich für die Thematik interessieren.

Falls du was anderes gemeint hast (threads beim Programmieren) wäre der Wikipediaartikel sicher für dich von Interesse.

[Blue-Tiger]

drakon schrieb:

Blue-Tiger schrieb:

drakon schrieb:

Solange nur jemand schreiben darf und die restlichen lediglich lesen, dann ist das auch kein Problem. Die Probleme kommen, sobald 2 Thredas auf etwas schreiben müssen.

meeeeep! Falsch!
Es kann auch dann zu Problemen kommen, wenn nur einer liest & einer schreibt. Siehe z. B. Producer-Consumer Probleme! Ausnahme: denn du kannst garantierten dass Read- & Wite-Operationen atomar sind und die Chaches zu jeder Zeit synchronisiert sind. Aber in der Regel kannst du das nicht.

Das hier wäre aber nicht wirklich ein Fall von typischem Producer-Consumer, denn es wird ja nichts aus einem Buffer genommen, sondern lediglich gelesen, was an dieser Stelle steht und nichts entfernt. Was das ist hat gar keinen Einfluss.

Nein, das ist kein typisches Producer/Consumer Problem. Ich wollte nur dem "solange nur jemand schreiben und alle anderen lesen, kann nix passieren" wiedersprechen. Denn genau das passiert bei P/C - Situationen, und bekanntermassen kann da einiges schief gehn

Das einzige, was da ja Probleme bereiten könnte, was ich mir vorstellen kann und du wahrscheinlich meinst, wenn ich dich richtig verstanden habe ist, wenn während dem Lesen der Thread unterbrochen wird, was dann natürlich auch blöde enden könnte, verstehe ich dich richtig?

Genau, wenn ein Thread mitten im Schreiben oder im Lesen unterbrochen wird (d.h. wenn die Reads bzw. die Writes nicht atomar sind), dann kann das ordentlich in die Hose gehen. Wird wie gesagt beim Verwenden von int auf einer x86-Maschine nicht passieren (Reads/Writes von ints sind bei x86 AFAIK atomar), aber im Allgemeinen ist das nicht der Fall (bei einem long long z.B. sind R/W meines Wissens schon nicht mehr atomar), weswegen der Threadersteller sich das lieber nicht so angewoehnen sollte.

[knivil]

(Reads/Writes von ints sind bei x86 AFAIK atomar)

Nein, sind sie nicht! Garnichts ist garantiert atomar bei x86 ausser vielleicht Compare-and-Swap. Extrembeispiel: Was ist wenn der int ausgelagert ist?

[trolled]

franz schrieb:

thread schrieb:

Was ist ein theard??

Ein Thread (gemeinhin als "Fred" bekannt) ist ein Thema in einem Forum.
Der erste Post (= Eintrag) kommt vom TO ("Theo" = Thread Opener). Meistens folgen viele Posts von vielen verschiedenen Menschen die sich für die Thematik interessieren.

Falls du was anderes gemeint hast (threads beim Programmieren) wäre der Wikipediaartikel sicher für dich von Interesse.

trolled.

[Blue-Tiger]

knivil schrieb:

(Reads/Writes von ints sind bei x86 AFAIK atomar)

Nein, sind sie nicht! Garnichts ist garantiert atomar bei x86 ausser vielleicht Compare-and-Swap. Extrembeispiel: Was ist wenn der int ausgelagert ist?

Na ja, solange er nicht direkt beim Schreiben unterbrochen wird, ist das ja immer noch atomar: Zu jedem Zeitpunkt hat der int entweder noch den alten Wert oder den Neuen (EDIT: und x86-Dualcores haben Cache-Cohaerenz, also sehen beide Threads entweder den alten oder beide den neuen Wert). Oder seh ich das falsch?

[hustbaer]

franz schrieb:

Der erste Post (= Eintrag) kommt vom TO ("Theo" = Thread Opener).

TO?
Wenn dann bitte OP (= Original Pos(t)er).

[Willy_Wonka]

Ist es normal bei theards das meine auslasstung beim öffnen eines Theards direkt auf 99% geht?

[Blue-Tiger]

Willy_Wonka schrieb:

Ist es normal bei theards das meine auslasstung beim öffnen eines Theards direkt auf 99% geht?

when du eine Endlosschleife (mit Busy waiting) drin hast, die unnoetig CPU verbraet (so wie im Code, den du gepostet hast): ja. Normalerweise aber nicht, nein.

[drakon]

Willy_Wonka schrieb:

Ist es normal bei theards das meine auslasstung beim öffnen eines Theards direkt auf 99% geht?

Dafür (oder besser dagegen) gibt es z.B unter Windows Sleep

http://msdn.microsoft.com/en-us/library/ms686298(VS.85).aspx

@Blue-Tiger:
OK. Dankeschön.

[Shade Of Mine]

Blue-Tiger schrieb:

Na ja, solange er nicht direkt beim Schreiben unterbrochen wird, ist das ja immer noch atomar: Zu jedem Zeitpunkt hat der int entweder noch den alten Wert oder den Neuen

Ja.
Aber wenn du Pech hast siehst du nie den neuen Wert

Fuer sowas eignet sich Compare and Swap - kann man schoen in eine atomic Klasse packen. Siehe zB die implementierung von boost shared_ptr.

[Blue-Tiger]

Shade Of Mine schrieb:

Blue-Tiger schrieb:

Na ja, solange er nicht direkt beim Schreiben unterbrochen wird, ist das ja immer noch atomar: Zu jedem Zeitpunkt hat der int entweder noch den alten Wert oder den Neuen

Ja.
Aber wenn du Pech hast siehst du nie den neuen Wert

Fuer sowas eignet sich Compare and Swap - kann man schoen in eine atomic Klasse packen. Siehe zB die implementierung von boost shared_ptr.

Warum seh ich den neuen Wert nie?
Ich kann verstehen wenn ich ihn "nicht sofort" seh (Race Condition), aber angenommen der Code rennt in einer Schleife: irgendwann seh ich ihn doch, oder? Oder denkst du an den Fall, dass der Compiler einfach das Read rausoptimiert (bzw. optimieren darf)?