This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I think it depends on the implementation of your JVM. If JVM is implemented as many to one model than one can define threads as process at JVM level. If JVM is implemented as many to many or one to one than one can't define it as process at JVM level.
For further information on type of Models implemented for MultiThreading Search google with keyword multithreading model
Chop your own wood, and it will warm you twice. - Henry Ford
Originally posted by Dinakar Kasturi: Is it ok to define thread as "process at JVM level"?
In disagreement with a previous poster, I would say that this is never a good analogy. Not for an application programmer, anyway.
Processes provide isolated execution environments. One process cannot directly access the data or code of another process. When writing code for a process, you do not have to worry that some other process will modify your data, or call your code, under your feet.
Threads provide parallel execution within a single environment. All the threads can access the same data and code. When writing code for multiple threads, you must always be aware of the possibility of other threads accessing your data and code.
This difference is so important to how you program for threads, compared to processes, that it completely invalidates your "definition", in my opinion.
For a system programmer (someone writing the code that implements threads and processes), I think there are greater similarities between threads and processes. Some operating systems have been known to call threads "Light Weight Processes" (LWPs).
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.