Goals
- Uniquely identify a Thread within one JVM
Thread/Runnable
- Each thread provides a thread id that is unique within one JVM
- Threads can only be started once (a second start will result in an exception)
- Thread pools
- Application server usually make use of thread pools, that is they re-use threads and just provide new Runnable instances to thread
- Thus the thread ID is not uniquely identifying a job that is executed by a thread, but one thread ID will in fact run multiple jobs
- The new Executor classes in Java6 provide an implementation of a thread pool
- Runnables
- Are used to execute jobs (in fact each Thread defines its functionality as Runnable)
- Runnables can be reused
Thread id + instrumented Runnable run-counter
One possibility to uniquely identify a "job that is run within another thread" even if thread pools are used is to instrument each Runnable run method with an additional counter that is increased every time the run method is started. So even if the Runnable is re-used a new identification will be created. In addition to that we could use the name of the Runnable realization class to differentiate between multiple Runnables realizations. To make this combination unique over multiple threads, we could integrate the thread-id.
Threads and Runnables using method eventing
Assumptions:
Assumption |
Correct? |
|---|---|
Within a thread a Runnable is bound until the Runnable itself is completed. In other words this situation cannot occur: runnable A runs partly, Thread decides to continue with runnable B and afterwards switches back to runnable A |
|
Threads can only be started once (the start method). This also means, that the thread identification within the JVM is unique (for each start of the JVM) |
|
Idea:
The "run" method of the executed runnable is instrumented. that means we get an event whenever the run method starts and when the run method ended. These two events span the lifecycle of the runnable itself. Thus by using this information we do not need to have any runnable id, as we know when a new runnable is executed by inspecting the methods that were started and ended in the current thread.
Possible problems:
- Runnable run method calls itself (would look like a new Runnable) [but in fact it is, is it not?]
- "run" method of the Thread itself will run forever for thread pools, but will on the other hand define the runtime of the thread (if not in a thread pool)