On Thu, 29 Jun 2006 14:16:49 +0200 Christian Thalinger <twisti@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 2006-06-29 at 10:35 +0100, Andrew John Hughes wrote: > > Based on your comments, it seems you agree with my original intuition > > of making this a native VM call (by default) in the majority of > > cases, but > > efficiency would seem to be fairly VM specific. > > > > I suppose I was aiming on lightening the load on the VM interface, as > > I seem to be throwing tons down there lately. I'd be interested in > > comments > > from other VM coders as to what they feel is best. > > For me it seems to be the better way to do this in the VM itself. > Although I'm not sure when I have to set which state :-) Enlighten me! > > TWISTI > Briefly, I think it goes as follows (anyone who knows better please point out any missing changes): * Threads are created in the NEW state * When started, they become RUNNABLE * If they enter a synchronized method and can't get the monitor lock, they are BLOCKED. This also happens when they reawaken from a wait() call in a synchronized method and try to get the lock again. * If sleep or join are called with time limits, they go into TIMED_WAITING. * Likewise, sleep or join without a time limit is WAITING. * I assume suspend() is a WAITING state for someone to call resume() (they are deprecated anyway) * Whenever a thread becomes unblocked or stops waiting, it goes back to RUNNABLE * When a thread dies, its state is TERMINATED Thanks, -- Andrew :-) Department of Computer Science University of Sheffield http://www.dcs.shef.ac.uk/~andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://developer.classpath.org/pipermail/classpath/attachments/20060629/aeac92ef/attachment.pgp
