On Tue, 11 May 1999 11:40:22 -0300 (EST), Carlos Cassino wrote:
>
>Hi.
>
>I'd like to comment a few points (please, correct me if I'm wrong):
>
>Michael:
>
>> Well, you are just assuming that threads of equal priority will switch
>> between each printout in your code.
>>
>> In fact, the Java spec says that threads do not have to yield unless they
>> are blocked by something (I/O or a monitor lock or...)
>
>That's perfectly right and, therefore, I think I can conclude that this is not:
>
>> As such, a large time slice or a very fast bit of code would make your
>> little test have the 100 lines of output per thread happen all in one
>> timeslice. (Depending on the buffering in the output stream, this is
>> not hard to do in today's hardware)
>
>Because even if your thread takes more than a timeslice to run, it will be
>perfectly able to continue so. Is that right?
The spec says it may continue to run. Or, if there is nothing else
waiting to run it may continue.
The spec for Java does not say that time slices need to be used but if
they are, then the size of the slice will also affect the "behavior"
of the multi-threading.
This all gets down to the fact that in multi-threading there is not set
way things will run unless/except at synchronization points.
A JVM can be implemented such that each thread runs on its own CPU - now
you have multiple threads actually running at the exact same time. What
behavior will you get then? Or you can be on one CPU with pre-emption...
Or it could be one CPU with cooperative multi-threading...
If code depends on the interaction of threads without some form of
synchronization or other locks/etc, then it will fail if the timeslice
gets longer or the CPU gets faster or you get multiple CPUs or you
have cooperative threading or... In other words, such code is broken :-)
I was just trying to point out all of the different ways the output would
be different than what the poster thought it "should" be. The code was
written in such a way that it could be anything and would change as
you changed the hardware (and in the Java world, as the JVM changed)
since there was nothing in the code to make it deterministic as to its
results.
Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
