Muss man "yield" bei der Thread Programmierung mit "abtreten" übersetzen?
-
Falls ja, dann ist die Beschreibung in den Docs zu Java SE 7 wesentlich besser, als die zu Java SE 6:
Java SE 7 Doc
yield() A hint to the scheduler that the current thread is willing to yield its current use of a processor.http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html
vs. Java SE 6 Doc
yield() Causes the currently executing thread object to temporarily pause and allow other threads to execute.http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html
-
abtreten ist mMn eine gute Übersetzung dafür
ich stimme dir zu die java 6 erklärung ist seltsam und erklärt nicht viel, da sieht yield aus wie ein sleep bei dem du dir die wartezeit nicht aussuchen kannst
-
Ich würde es am ehesten mit "überlassen" bzw. "verzichten" übersetzen - aber "abtreten" kommt auch hin.
Wobei die Erklärung in der Java SE 6 Doku es doch auch gut trifft. Es ist ja im Prinzip ein Sleep mit undefinierter Wartezeit.
-
hustbaer schrieb:
Wobei die Erklärung in der Java SE 6 Doku es doch auch gut trifft. Es ist ja im Prinzip ein Sleep mit undefinierter Wartezeit.
Es klingt aber so, als ob auf jeden Fall der Thread schlafen gelegt wird, nicht bloß, wenn ein anderer Thread Bedarf anmeldet.
Falls die Funktionen wirklich beide das gleiche tun (und zwar das, was ich vom Namen her erwarte), dann ist die Formulierung in Version 7 wesentlich besser.
Version 6: sleep(random time)
Version 7: Priorität senken.P.S. Laut google macht yield nicht genau das, was ich erwarte. Demnach finde ich die Version 6 doch treffender.
-
@SeppJ
Was hast du denn erwartet?Auf Windows sollte yield() als SwitchToThread() implementiert sein, d.h. es sollte den Rest der aktuellen Zeitscheibe an einen anderen "ready" Thread abgeben - auch wenn dieser niedrigere Priorität hat.
Der yield()ende Thread wird dabei genau so wieder in die Warteschleife eingereiht als ob er seine Zeitscheibe aufgebraucht hätte.
Und wenn es keinen anderen Thread gibt der auf ne CPU wartet, dann läuft der yield()ende Thread einfach normal weiter.
-
hustbaer schrieb:
@SeppJ
Was hast du denn erwartet?Ein temporäres Senken der Schedulingpriorität. Nicht die zwangsweise, aktive Aufgabe des aktuellen Slices. Was im Prinzip ziemlich genau die gleiche Auswirkung hat, sich aber im (durchaus wichtigen) Detail unterscheidet, wie mit der aktuellen Zeitscheibe verfahren wird.
-
Hat yield() denn ueberhaupt einen Nutzen? Die Funktion gibt ja absolut gar keine Garantie, ob und wie lange der aktuelle Thread schlafengelegt wird und ist damit z.B. fuer lock-free programming nicht besonders nuetzlich um busy-waits zu vermeiden.
-
Klar ist die nützlich.
Nur weil das genaue Verhalten nicht definiert ist, heisst das ja nicht dass etwas nicht nützlich ist.
-
Kannst du mir dann erklaeren, warum yield() gegen busy-waits immer wieder verwendet wird? Theoretisch koennte yield auch einfach nichts tun.
void yield() {}
-
*facepalm*
Weil es praktisch eben nicht nichts tut.
Warum schreibt man ein
rep nopin den Spin-Loop einer Spinlock?
Warum spint man mit einer non-atomic Instruction, und verwendet erst ein CAS Primitive wenn der non-atomic Test "OK" ergeben hat?Warum macht man überhaupt was im Leben?
-
Wenn yield nichts tut, hat man gegen einen Busy-Wait genau gar nichts getan.
-
Kellerautomat schrieb:
Wenn yield nichts tut, hat man gegen einen Busy-Wait genau gar nichts getan.
Es tut ja nicht "nichts", man sagt dem OS "hey, wär ein guter Zeitpunkt mal die anderen ranzulassen, ich muss eh nur warten". Jetzt kommen andere Prozesse zum Laufen und du verbrätst nicht deren Zeit auch noch.
MfG SideWinder
-
Dass andere Prozesse drankommen, ist aber nicht garantiert. Das OS kann auch einfach gar nichts machen und den Thread weiterhin ausfuehren.
-
Kellerautomat schrieb:
Dass andere Prozesse drankommen, ist aber nicht garantiert. Das OS kann auch einfach gar nichts machen und den Thread weiterhin ausfuehren.
Es ist nur deshalb nicht garantiert, weil es evtl. ja gar keine anderen Prozesse gibt die etwas tun wollen. Das Betriebssystem nimmt dein yield() schon ernst, keine Sorge, es weiß schon was es tut.
Aber nur weil es *evtl* mal auch nichts tut, kannst du doch nicht sagen yield() würde generell nichts bringen?!
BTW: Busy wait ist auch mit yield() natürlich nur für die Einsatzzwecke geeignet wo dies in der Literatur erwähnt wird, es macht natürlich auch weiterhin keinen Sinn in user-level Code mit BusyWait auf User-Input zu warten...
MfG SideWinder
-
@Kellerautomat
Kannst du eigentlich auch noch was anderes sagen? Versuchst du überhaupt zu verstehen was wir dir schreiben?Angenommen du hast nen Busy-Wait Loop. Und angenommen das lässt sich nicht vermeiden.
Was ist dann wohl schlauer:
A) Ein Yield() einbauen, und dem OS damit die Möglichkeit geben das ganze etwas zu entschärfen
oder
Nix machen, weil ja sowieso nicht garantiert ist dass das OS überhaupt was tut?Wobei man es mMn. durchaus als garantiert ansehen kann dass das OS was tut. Nur dass nicht definiert ist was genau gemacht wird. Was auch gut so ist, weil das OS/Framework/... dadurch die Möglichkeit hat hier in Zukunft diverse Verbesserungen zu machen.
Was ist daran jetzt so schwer zu verstehen?
-
guckt doch mal in die java 7 dokumentation:
yield muss nicht zwingend vom Scheduler beachtet werden
yield kann benutzt werden um zB busyWaits cpu nutzung zu entschärfen aber man sollte es nur benutzen wenn entsprechende Messungen positiv ausfallen
und das wichtigste yield braucht man meist nicht
-
Kann das mal bitte jemand nach Java schieben, da es nur um das yield in Java geht. Ich muss autmatisch an Coroutinien, kooperatives Multitasking, MS-DOS, etc. denken, aber nicht an Java.
-
@gary1195
Ja, schön.
Trotzdem ist die Funktion nicht sinnlos.
-
hustbaer schrieb:
@gary1195
Ja, schön.
Trotzdem ist die Funktion nicht sinnlos.Das habe ich nicht behauptet!
-
@gary1195
Dann entzieht sich mir der Sinn deines Beitrags
