RE: user-space threads

["Boehm, Hans" <hans_boehm at hp dot com>]

> -----Original Message-----
> From: Adam Megacz [mailto:gcj@lists.megacz.com]
> 
> Wow, I just checked the JLS, and you're right.  This is amazing.  It
> doesn't even require the conventional "scheduler must not starve a
> runnable thread forever" assumption.
I assume you meant to add the condition that there are no higher priority runnable threads.  I personally would be happy to drop that condition in many contexts, but I think that's controversial.

I agree that ideally a desktop or server JVM should have that property.  But there are many implementations that don't.  Sun Classic "Green Threads" JVMS didn't.  At least many years ago when I last used it, Solaris threads didn't.  (Lwps were timesliced, but threads running on an lwp weren't.  I don't know if that's changed.)  I'm not sure that NGPT threads have that property.  It looked to me like they behaved like old Solaris threads, last I attempted to read the code.

The issue came up in the Java memory model discussions.  There are almost certainly contexts in which a VM should not be required to enforce the above.  (E.g. for a VM running database stored procedures.)  Hence it probably shouldn't be in the spec.
> 
> Wow.  I consider that a major omission.  A lot of people write code
> that implicitly relies upon that assumption -- for example, a lot of
> crypto libraries generate randomness by spinning a thread in a while
> loop and then flipping a boolean to break the thread out of the loop.
> 
In many cases (e.g. Sun Classic VM, some Netscape VMs) you can make that work by having a higher priority thread wake up regularly and immediately go back to sleep, forcing occasional reschedules.  My constructive reals calculator had to do that to allow asynchronous interruption.  But it's not guaranteed to work either.

Hans