Joseph Bowbeer wrote:
> 1. In a background thread in a GUI app in an attempt to make the UI more
> responsive. The background thread yields periodically in order
> to give the event-dispatch thread as much time as it needs (but no more).
I'd be more inclined to use priorities for this. In fact the event thread is
normally/often/sometimes set to NORMAL_PRIORITY+1 for just this reason,
under the assumption that nobody uses anything other than NORMAL_PRIORITY
for other application threads :-)
> 2. As a temporary tweak to the JVM's thread scheduler until I get
> around to implementing my own scheduler.
To replace the VM's scheduler??? ;-)
> I think it's fine to keep Thread.yield() vague. I would define yield as a
> "suggestion" or "hint" to the JVM. On return from yield, the JVM
> will have made its "best effort" to give some other thread a chance to
> run, pausing the current thread if needed. Such a definition wouldn't
> change the fact that Thread.yield() doesn't have to "do" anything. (Is
> this any different to how yield is defined now?)
Yield is indeed a hint to the scheduler. The difference between what is
proposed and what is the current situation (in my view) is that the current
vague spec doesn't require yield to do anything in any circumstances. The
revised spec requires yield to do something in those circumstances where not
doing anything would allow a thread deny all other threads any chance of
executing to any extent.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:36 EDT