Update: The Process object in dotnet is another “handle” on a OS construct…
Suppose a virtual machine thread FastRunner is linked to a Thread Object TO2.
A) As a java object, a Thread.java object TO2 is a chunk of HEAP mem, and can have fields.
B) As a real thread ie “vm thread”, FastRunner occupies memory for its call stack and can receive cpu cycles.
In general, a call stack can have “access” to any heap object if you pass in a (indirect) reference. TO2 is a heap object and can be accessed on the call stack of FastRunner. In fact it’s dead easy. Thread.currentThread() will return a TO2 reference. This is a embrace.
1) TO2 has a pointer to the call stack of FastRunner and can affect FastRunner in a few limited ways.
2) among the local variables of the call stack, there’s now a pointer to TO2.
A field f1 in TO2 is not related to anything in the vm thread FastRunner. You might potentially want to use TO2 fields to control FastRunner, but TO2.f1 is just like a field in any heap object.
Fundamentally, TO2 has a pointer to the FastRunner vm thread. JVM provides no reference to FastRunner as it’s not on the heap and not a java Object.
Suppose you have a (usually stateless) Runnable object R2. It is basically a function pointer. R2 has nothing but 4 bytes holding the address of run() method which lives in Code Section, not stack not heap. You can pass R2 to Thread() ctor to create TO2 object. TO2 has a different address than R2 though.
If TO2 is a television remote control, then it offers a small number of “buttons” to control FastRunner, like
- * interrupt()
- * join() – will block the current thread
- * stop() – deprecated but still useful as in SureStop.java
- * start(). – could be useful to control timing
- Note run() should never be called except by start()
– if you have a java reference to the TO2 object, you can’t use it to make FastRunner sleep
– if you have a java reference to the TO2 object, you can’t use it to make FastRunner grab a lock
– if you have a java reference to the TO2 object, you can’t use it to make FastRunner wait in a monitor
– if you have a java reference to the TO2 object, you can’t use it to notify FastRunner
I’d say the remote control is so limited that most of the important “buttons” are missing. As explained below, TO2 is a “poor” handle on the vm thread (FastRunner) known as a “thread” with its call stack, thread registers, cpu cycles etc. Better to avoid confusion — distinguish “Thread” and “thread”. P27 [[java threads]] explains
* when a vm thread in VM is running its run() method, both the VM thread and the Thread object are connected. TO2 is a relatively good handle on the vm thread in VM.
* after run() returns, vm thread no longer gets cpu cycles, but the Thread object is still useful until it’s garbage collected.
* after you instantiate a Thread, but before you call its start(), the call stack doesn’t exist.
* bottom line — Thread object lives a bit longer than a vm thread.
If you naively think that an instance method in TO2 is related to the corresponding call stack of FastRunner, then you are wrong on multiple accounts.
* if FastRunner run() method calls such a method m1(), then the method runs on FastRunner, but m1() body may have nothing to do with the VM thread FastRunner.
* As explained earlier, Thread has longer lifespan than thread, so any method call made outside FastRunner’s lifespan is unrelated to FastRunner the vm thread.
* the main thread can call any of those methods. Such method calls may have nothing to do with the VM thread’s call stack.
In terms of programmatic control on the vm thread, D) is most useful, followed by B and C —
C) thread instance methods — least used. Quiz — can you name 2?
TO2.interrupt() is one of the few important instance methodS. Others include run(), join() and the associted isAlive(). These operations can be invoked on main thread or another thread. They mostly affect the current thread not the target thread.
B) Thread.java static methods let you probe/modify the thread to some extent, such AS Thread.sleep(). These Thread methods are static methods, without a specific Thread instance as the target. They usually affect the current thread. The static and non-static mix in Thread.java is confusing. I feel these should be put into a ThreadControl.java class and converted to instance methods, and instantiated as a static member of System, just like System.out.
D) Many of the modifications, controls && operations on the thread are effected through constructs outside the Thread instance, such as wait(), the all-important keyword synchronized, which is similar to the Lock.lock() …
There’s something like TO2.isInterrupted() instance(!) method which is often called — Thread.currentThread().isInterrupted().