[cp-patches] FYI: Handle thread state
Andrew John Hughes
A.Hughes at dcs.shef.ac.uk
Thu Jun 29 13:55:12 UTC 2006
On Thu, 29 Jun 2006 14:16:49 +0200
Christian Thalinger <twisti at complang.tuwien.ac.at> 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!
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
Department of Computer Science
University of Sheffield
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060629/aeac92ef/attachment.pgp
More information about the Classpath-patches