On 10 Feb 2001, Juergen Kreileder wrote:
> >>>>> "Dimitris" == Dimitris Vyzovitis <[EMAIL PROTECTED]> writes:
>
> Dimitris> On 9 Feb 2001, Juergen Kreileder wrote:
> >> BTW, it's "Thread.yield()". "Thread.currentThread().yield()"
> >> has exactly the same meaning but as Thread.yield() is a class
> >> method you should call it directly on the class.
> >> "Thread.currentThread().yield()" makes it look like yield()
> >> would be an instance method.
>
> Dimitris> Yes, but all operations refer to the current thread, and
> Dimitris> conceptually refer to the same object. Since java is
> Dimitris> positioned as a concurrent object oriented programming
> Dimitris> language, the class instance (actor) behaves as a
> Dimitris> forwarder for the current thread object (actor), and
> Dimitris> semantically it is perfectly legal to bypass the
> Dimitris> forwarding step and be explicit.
>
> You don't bypass anything here.
>
> Thread.yield();
>
> and
> Thread.currentThread().yield();
>
> and even
>
> Thread t = null;
> t.yield();
>
> have exactly the same meaning, they all work on the thread executing
> the code.
this is exactly what I said above. I didn't imply that you bypass
anything.
> The first one is the preferred form as it clearly shows
> that that yield() is class/static method of class Thread. The second
> variant just adds useless code.
> And the latter one may really confuse
> some people.
I explained above that I personally see it semantically cleaner to do
Thread.currentThred().yield()
>
> Dimitris> Btw, it might be interesting in an smp machine to have
> Dimitris> the capability to instruct other threads to yield. The
> Dimitris> current spec makes a_thread.yield() meaningless
> Dimitris> (<any_thread>.yield() ==
> Dimitris> Thread.currentThread().yield()). This could be useful in
> Dimitris> user-space scheduler implementations and a mixed
> Dimitris> threading model.
>
> Not really. In these cases you want to control which thread gets cpu
> time next. Just yielding other threads doesn't give this control.
I was thinking of sth simpler: adding a NOOP as the next instruction of
the target thread. A call equivalent to cputimes() would be helpfull as well.
Their use could be to implement round robin schedulers in user space.
> You're better off implementing such things at a lower level.
Agree, but this requires access to vm internals.
>
> Dimitris> As far as the correctness of yield behavior is concerned
> Dimitris> you are right (it does sth the jls correcness criteria
> Dimitris> and does not violate strong fairness conditions), but
> Dimitris> there is definetely sth instructive in the way the
> Dimitris> test_yield program behaves. If there is no I/O thread
> Dimitris> involved, then all threads get approximately equal run
> Dimitris> occurences (see test_fairness, attached).
>
> I'm not sure what you want to show with test_fairness. You have three
> threads which all count up to the same number. Then finally you print
> out the three counters which always will be the same. There's nothing
> in this code testing fairness of scheduling.
Two things: first that all threads run equally often (this is the
farinees test, succeeds). Second, to illustrate that the behavior of the
vm changes substantially from the behavior observed in test_yield, in a
manner that appears to be inconsistent.
>
> Dimitris> If you run test_yield with a longer sleep period, you'll
> Dimitris> notice that there is a dominant thread which gets approx
> Dimitris> as many runs as the other two. Although this does not
> Dimitris> violate the fairness conditions imposed by the jls, it
> Dimitris> is not quite what I expect given the perfectly fair
> Dimitris> behavior when no i/o is performed.
>
> Ah, fix test_fairness and you'll see that it isn't IO related.
>
> Dimitris> Once again, this is not a bug in the blackdown vm since
> Dimitris> it still satisfy the jls, but the behavior of ibm's vm
> Dimitris> is more *consistent*.
>
> [Actually, I would consider such a significant difference a bug.]
>
> As said in my previous posting: The difference you see is is not
> caused by scheduling and/or a specific Thread.yield() implementation.
> You just see a comparison of _interpreted_ vs _compiled_ code.
Intersting of you to say. So, does the presence of the jitter modify vm
behavior so drastically? Isn't the bahavior of the vm without jit
inconsistent? I think that this deserves some more attention.
-- dimitris
mailto:[EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
