Hi, I'm not able to understand the below statement. a thread of execution is an individual process (a �lightweight� process) that has its own call stack. In Java, there is one thread per call stack�or, to think of it in reverse, one call stack per thread.
in short this means there are more than one simultaneous threads of execution which are working through the same program code (possibly at different places in the code) but with shared access to common data. It's a bit like starting the same program more than one time and all programs running simultaneously in parallel. Of course real parallel execution is only possible if you have more than one CPU in your computer.
This was only a very short and imprecise explanation though. In practice multi-threading is somewhat more complicated. In particular this thing with the "shared data" makes it more complex
Do you talk about the resources use by the threads? These are simply the usual resources of your computer like memory, CPU or I/O devices. There's often a good chance to use them more effectively when using multiple threads.
Call stack is area where CPU keep track of memory and instructions and all the program information needed to stay running. These could not be readily shared between two threads because that is the machine in actual operation.
If two ( logical ) processors tried to use the same control block, it always seems to hang sooner or later or data gets corrupted or in one way or another something just does not work right.
The explainations in the books need to get a little closer to an actual machine to be suitable for the intended purpose.
Call stack is area where CPU keep track of memory and instructions and all the program information needed to stay running. These could not be readily shared between two threads because that is the machine in actual operation.
This is not an area in the CPU. It's some kind of data structures the runtime environment of a program (not just Java) needs to keep track of function/method calls together with parameters and return values and jump addresses. I didn't mean this kind of data which is shared among threads but member variables in your objects.
Anyway for simplification I think "call stack" in this context just means one execution thread of a program without a focus on such data structures. Accordingly you have more than one call stacks if you have more than one threads executing the same code (because each threads needs its own call stack).
it always seems to hang sooner or later or data gets corrupted or in one way or another something just does not work right.
Funny explanation of multi-threading issues but it gets to the point. This "seems to hang" or "gets corrupted" errors are well-known issues when trying to execute non-thread-safe code with multiple threads. There are race conditions, data races, dead locks, visibility problems and and and... But that's not easy enough to explain here in a few words.
The "Java Concurrency in Practice" book of Brian Goetz gives really interesting and detailed answers and information regarding multi-threading. It's probably better to give this a try instead of long discussions here
Marco
[ June 02, 2008: Message edited by: Marco Ehrentreich ] [ June 02, 2008: Message edited by: Marco Ehrentreich ]
Originally posted by Marco Ehrentreich: It's probably better to give this a try instead of long discussions here
Let that be our conclusive advice to original poster.
Funny explanation of multi-threading issues but it gets to the point. This "seems to hang" or "gets corrupted" errors are well-known issues when trying to execute non-thread-safe code with multiple threads. There are race conditions, data races, dead locks, visibility problems and and and... But that's not easy enough to explain here in a few words.
I was trying to achieve effectiveness in serving the poster's needs, I am actualy moderately sensitive but have developed at 'Hit me with your best shot' style as a consequence of trying to get things done on large projects.
Area of cpu? Ever seen the P-8 overlay? How about a 64x64 gated architecture running no-write-back Inventory Tracking and Control. [ June 02, 2008: Message edited by: Nicholas Jordan ]
Let that be our conclusive advice to original poster.
Good idea
I was trying to achieve effectiveness in serving the poster's needs
So was I. As I admitted this topic is not easy enough to explain every little detail here, so I'm sure my first posts wasn't 100% technically correct.
Area of cpu? Ever seen the P-8 overlay? How about a 64x64 gated architecture running no-write-back Inventory Tracking and Control.
Sorry, I'm absolutely not familiar with current hardware. I just think that "call stack" in the original post didn't mean the hardware handling of stacks, registers or memory but the handling of the call stack the runtime software or compiler has to take care of. So for my explanation the call stack was this little data structure consisting of activation records you have to manage if you write an interpreter for example. I'm sure there are other contexts for it so your answer surely was not wrong but something totally different than my answer
Now I think this is enough confusion for Phillipe Phillipe, just take out the essence of our discussion here...
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
Phillipe, just take out the essence of our discussion here...
