The concept comes from decades ago where you had a main task (process) and that task created sub-tasks (threads). If the main task died, all it's sub-tasks died too. Each sub-task inherited all its properties from the main task and could change very little, hence a light-weight. Actually this concept has morphed over time.
Java doesn't support that concept. All threads are equal. If the main thread dies, the non-daemon threads it created continue autonomously.
Originally posted by Edward Harned: Java threads are not light weight...
The idea of a thread as a "light-weight process" has nothing to do with parent/child relationships, so I don't know where that's all coming from. The term refers to the fact that a Thread doesn't have its own address space, nor its own set of file buffers, nor most of the other things that a process has; the only thing it has is its own stack and register file. All the threads in a process share a memory space and everything else that belongs to their process. Therefore a thread is relatively quick and easy for the OS to create, as compared to a whole new process, which is a relatively expensive affair. "Lightweight" refers to this simplicity and ease of creation.
Yes. When you create the *first* thread, during the creation of the process, it is definitely not lightweight. However, once the process is running, generally requesting that the OS create another thread to run a task, is much lighter weight than requesting that the OS create another process to run a task.
Originally posted by Rahul Toaikani: So why is first thread not-light weight and the 2nd onwards are light-weight?
All threads are light-weight (relative to processes), but to create the first one for a process, the original question is assuming to have to create a process too.... Okay, so the original question is badly worded.
Henry [ March 09, 2007: Message edited by: Henry Wong ]
I don't think the thread's lightweightness is because of the cost of creating the thread. I would argue its more associated with the resources it occupies. Processes use more system resources than threads. Well its not that they use more. Processes contain threads, so it uses everything a thread uses, and then some. A thread does not exist outside of a process.
Joined: May 07, 2007
what are the system resources the thread and process uses?
Joined: Apr 22, 2007
hi Ernest Friedman-Hill ,
I think you are right....i think it is related to some OS concepts because any process has the PCB ( process control block )and has it's memory to run the process... please explain a bit... what the process has and what the thread does not have (which makes it light-weight) -- so that it would help all of us.
Thanks, vinay rajnish
author and iconoclast
please explain a bit... what the process has and what the thread does not have (which makes it light-weight) -- so that it would help all of us.
The details vary a great deal by operating system, of course. But traditionally a thread has a stack, and a register file, and maybe some extra status bits, and that's about it. A process has at least all that, plus a whole memory space of its own with its own memory map including a heap to manage and the application code, maybe some I/O buffers, etc. That stuff takes a lot of computational work to set up. All the threads in a process share them, so creating a process is a lot more work than creating a new thread in that process.
Joined: Sep 17, 2006
Originally posted by Ernest Friedman-Hill: The details vary a great deal by operating system......
So, therefore, would also the definition of why threads are light weight.
Originally, paging in the executable in any linguistic involves a disk-head access ... then once the load and link are resolved, the jump-main() can be re-entrant from transient cache.
The definiton of light weight vary a great deal by Anant's design goals.
If Anant's design goals allow only one thread to be capable of running the process, should she call that thread the main() thread ?
Joined: Apr 19, 2005
Suppose process 1 contains (thread1,thread2) and process 2 contains (threadA,threadB). The OS alternately picks thread1 and then threadA. Does threadA still considers lightweight.
Joined: Sep 17, 2006
Originally posted by vu lee: Does threadA still considers lightweight.
It is my opinion that any thread, after the main() in called, is a lightweight. Others may voice differing assesments, may I suggest testing ?
There is no substitute for testing, but what are you trying to determine ? It appears you are trying to grasp the concept, and should consider the physical device to resolve the matter.
Originally posted by vu lee:
Suppose process 1 contains (thread1,thread2) and process 2 contains (threadA,threadB). The OS alternately picks thread1 and then threadA.
The matter of scheduling, whether between Threads or between Process(s) is deeply buried in implementation details that are not likely to be exposed at source code, and trying to affect such matters is likely counter-productive for a linguistic like Java that was concepted to remove some knotty challenges that are well known to compiler authors and studied extensively in computer science. Generally, to answer your specific question here, the OS will not generally pick Thread (t-1) in Process (p-1), then round-robbin like a cork-bobbin over to Thread (t-n) in Process (p-n) .... what it will do, generally, is try to allow a process that is working to get some work done before it schedule another process.
Managing this switching can only be effected by compiler authors, and any machine that has the hardware to simultaneously run several threads will still have the load & link to resolve. We can safely forget about load & link while writing in Java, probably better if we do ... just remember that Threads of execution occur within a process, and do not cross process boundaries.
Further questions welcome.
[ May 24, 2007: Message edited by: Nicholas Jordan ]