[224] in java-interest

home help back first fref pref prev next nref lref last post

Re: Threads vs New White Paper

daemon@ATHENA.MIT.EDU (Jim.Graham@Eng.Sun.COM)
Wed Jun 7 20:30:49 1995

Date: Wed, 7 Jun 1995 17:20:33 -0700
To: johnm@medicus.com
Cc: java-interest@java.Eng.Sun.COM
From: Jim.Graham@Eng.Sun.COM


Hi John,

> So, my question becomes: what then is the *real* specification of the
> thread support in Java?  I.e., if I as a developer cannot count on
> preemptive threading then I end up having to explicitly do all of that
> yield() calling crap.  That's no better than not having thread support
> in the language.

What Jon was saying is that the specification is:

	Higher priority threads are guaranteed to preempt lower
	priority threads when they become eligible to run.

That is all.  There is no guarantee that threads within a given
priority will time slice or preempt each other when one becomes
eligible to run, but such behaviour is also not prohibited.  The
current thread package on Solaris does not time slice.  If we ported to
native threads on Solaris we would presumably get time slicing for
free, but neither is guaranteed.

Absence of yield()'s in your code will not interfere with the operation
of the browser since the UI code runs at a higher priority than the
typical Applet thread, but other Applets may be starved.  If you have
a long calculation you can either yield, or you can run it at a lower
priority to prevent starving Applets that are merely performing
interaction calculations.

				...jim
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post