Hi all,
I have several threads. And I'd like to create sub-threads in one of them. So I'd like know whether java thread has a tree structure. Or the new created sub-threads is just the sibling of other threads. And What's the resource allocation strategy when these thread are competing for resources? Does the parent thread has higher priority ? Thanks.
Jeff
There is no concept of "subthread" in the way you describe, certainly no (apparent) tree structure. You can adjust the priority of threads if you like, though the actual meaning of thread priority is essentially undefined (unless you go to RTSJ). CPU resource allocation, by and large, is managed by the OS scheduler... you can try to influence it with priorities, but again that's a dicey proposition.
If you are looking for a framework to break a problem into subcomponents and process them concurrently, look at JDK5/JDK6's java.util.concurrent package, with specific attention to Callable and the Executor framework. Also, the ForkJoin framework might match.
Threads do not strictly have a tree structure. However, you can use ThreadGroups to make a hierarchical nesting of Threads and other ThreadGroups.
I don't believe that there is a hard rule for thread priority inside groups, as each thread can be set separately.
Why do you need "sub-threads"? In my experience, Thread should be avoided in favor of ExecutorService. The service won't give you a hierarchy of stuff easily, but I'm having a hard time thinking of a case where the hierarchy would be useful.
There's no thread hierarchy, all threads are siblings of each other. There is no concept of "parent thread" or "child thread". You'll have to be more specific about what you mean by resource allocation strategy -- what resources are you referring to?
If it's memory (by far the most common type of resource), then the answer is that the memory allocator is thread safe: multiple simultaneous allocations happening on different threads will always work correctly. If you run out of memory, then some unlucky thread is going to get an OutOfMemoryError.
If you're referring to other types of resources, then it depends entirely on the implementation of the resource. It's either going to be thread-safe or non-thread-safe. If it's thread-safe, you can allocate the resources freely from multiple threads. If it's not thread-safe, then read the documentation for that type of resource.
The closest that there is to a thread hierarchy in Java is the ThreadGroup. By default, every application thread goes into the same ThreadGroup, but you can create new ThreadGroups and create new Threads within them. ThreadGroups are inherently hierarchical, and offer methods for doing things like enumerating the threads and child groups, interrupting all threads, setting a default uncaught exception handler, and so on.
Unfortunately, this doesn't do what you want to do. In particular, thread groups are not taken into account when allocating resources or scheduling.
There is a setMaxPriority method, but it only (indirectly) affects new threads or existing threads that change priority. Existing threads whose current priority is greater than the new "max" are not changed. So even this is not much use if you want to alter the priority of a number of threads.
(I understand, that the primary motivation of thread groups was to enable things like suspending or killing a bunch (herd?) of related threads. But that went out of the window when the Sun engineers realized that suspending and killing threads was fundamentally unsafe.)
Thread inherit a default priority from their parents (the one which created them) however this is just a hint and is ignored in many cases on most OSes.
Threads are designed to share resources as much as possible in as light wieght (ie simple) way possible. If you want to manage resources of tasks you need to have different processes. However these are not simple or light weight i.e they are much more expensive resource and code complexity wise.
What sort of problem are you trying to solve? It is likely for any problem there is a fairly simple solution.