java thread question

M

mcheung63

Hi All
I have write a little program to keep running some threads, i got questions:
1) All threads are running within one process (ps command show me this), but it will eat up all cpu cores, how to explain this?
2) If thread will eat multiple cpu core, why wee need fork/join in java?

public class TestThread implements Runnable {
public static void main(String args[]) {
for (int x = 0; x < 10; x++) {
new Thread(new TestThread()).start();
}
}

@Override
public void run() {
double r = 1.2323;
while (true) {
r = r * r + Math.pow(r, r);
}
}
}



thanks
from Peter ([email protected])
 
N

Nigel Wade

Hi All
I have write a little program to keep running some threads, i got questions:
1) All threads are running within one process (ps command show me this), but it will eat up all cpu cores, how to explain this?

Because the OS can normally schedule any runnable process/thread to run on any available CPU core.
If your process has sufficient threads which are runnable then every core will be used.
One of the main purposes of threads is that they offer concurrent execution.
2) If thread will eat multiple cpu core, why wee need fork/join in java?

Fork starts another process, and this may run an entirely different executable.

If your only goal is to consume CPU then you don't require fork.
 
E

Eric Sosman

Hi All
I have write a little program to keep running some threads, i got questions:
1) All threads are running within one process (ps command show me this), but it will eat up all cpu cores, how to explain this?

What needs explanation? That is, what puzzles you? The *purpose*
of threads is to break up a large task into smaller pieces and let them
execute in parallel; you *want* those smaller pieces to use whatever
machine resources they can get.
2) If thread will eat multiple cpu core, why wee need fork/join in java?

(I assume you're referring to java.util.concurrent.ForkJoinTask.)
If your large task subdivides into a million smaller pieces, you don't
want to try running each piece in a separate thread. A thread is
"lighter-weight" than a full-scale process, but its weight is non-zero:
There's a stack, there's other CPU context, there's management overhead
like schedulers and garbage collectors, ... When you multiply this by
a million, or even by several thousand, your system will collapse under
the load, most probably by throwing an OutOfMemoryException.

That's where ForkJoinPool and ForkJoinTask come in. The pool runs
a manageable number of long-lived threads, and each thread executes many
ForkJoinTasks in succession. (There are additional intricacies, but
that's the essence.) You don't have to create, start, shut down, and
garbage-collect a million threads to get the million sub-tasks done.
 
M

mcheung63

Eric Sosmanæ–¼ 2014å¹´4月3日星期四UTC+8下åˆ11時43分54秒寫é“:
What needs explanation? That is, what puzzles you? The *purpose*

of threads is to break up a large task into smaller pieces and let them

execute in parallel; you *want* those smaller pieces to use whatever

machine resources they can get.






(I assume you're referring to java.util.concurrent.ForkJoinTask.)

If your large task subdivides into a million smaller pieces, you don't

want to try running each piece in a separate thread. A thread is

"lighter-weight" than a full-scale process, but its weight is non-zero:

There's a stack, there's other CPU context, there's management overhead

like schedulers and garbage collectors, ... When you multiply this by

a million, or even by several thousand, your system will collapse under

the load, most probably by throwing an OutOfMemoryException.



That's where ForkJoinPool and ForkJoinTask come in. The pool runs

a manageable number of long-lived threads, and each thread executes many

ForkJoinTasks in succession. (There are additional intricacies, but

that's the essence.) You don't have to create, start, shut down, and

garbage-collect a million threads to get the million sub-tasks done.



--

Eric Sosman

(e-mail address removed)

Thanks, that mean the advantage of fork/join is : I don't need to manage a thread pool by myself.
 
E

Eric Sosman

[...]
[... more quoting than needed ...]
[... all of it double-spaced ...]
[...]
Thanks, that mean the advantage of fork/join is : I don't need to manage a thread pool by myself.

Yes, largely. Note, too, that the efficient management of task
counts in the millions is no easy matter, so another advantage is
"I don't need to *invent* a super-efficient thread pool myself."
 
R

Roedy Green

I have write a little program to keep running some threads, i got questions:
1) All threads are running within one process (ps command show me this), but it will eat up all cpu cores, how to explain this?
2) If thread will eat multiple cpu core, why wee need fork/join in java?

what do you mean by "eat"?

Threads join the queue of processes to execute. the OS schedules them
on the next available CPU core. So if you have 7 threads and 4 cores,
you can have 4 of those threads running at once.

Your threads compute just like independent jobs, though the OS can do
proprietary clever things.

When you exec/fork, you spin off a separate job than runs
independently in a separate address space. The spawner can fail and
the child keeps going. The child can be written in a different
language. The child have very limited ability to communicate with the
spawner. A thread has access to the shared address space directly.
 
M

mcheung63

Eric Sosmanæ–¼ 2014å¹´4月4日星期五UTC+8上åˆ7時00分46秒寫é“:
[... more quoting than needed ...]
[... all of it double-spaced ...]

Thanks, that mean the advantage of fork/join is : I don't need to manage a thread pool by myself.



Yes, largely. Note, too, that the efficient management of task

counts in the millions is no easy matter, so another advantage is

"I don't need to *invent* a super-efficient thread pool myself."



--

Eric Sosman

(e-mail address removed)

Thanks Eric
 
M

mcheung63

Roedy Greenæ–¼ 2014å¹´4月4日星期五UTC+8上åˆ8時52分54秒寫é“:
what do you mean by "eat"?



Threads join the queue of processes to execute. the OS schedules them

on the next available CPU core. So if you have 7 threads and 4 cores,

you can have 4 of those threads running at once.



Your threads compute just like independent jobs, though the OS can do

proprietary clever things.



When you exec/fork, you spin off a separate job than runs

independently in a separate address space. The spawner can fail and

the child keeps going. The child can be written in a different

language. The child have very limited ability to communicate with the

spawner. A thread has access to the shared address space directly.



--

Roedy Green Canadian Mind Products http://mindprod.com

"The question of whether machines can think is about as relevant

as the question of whether submarines can swim"

~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)

thanks Roedy
 
M

mcheung63

Roedy Greenæ–¼ 2014å¹´4月5日星期六UTC+8上åˆ12時49分54秒寫é“:
On Thu, 03 Apr 2014 17:52:54 -0700, Roedy Green


someone who said :








for more detail, see http://mindprod.com/jgloss/exec.html



I have updated the essay and will not upload it for an hour or so.

--

Roedy Green Canadian Mind Products http://mindprod.com

"The question of whether machines can think is about as relevant

as the question of whether submarines can swim"

~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)

Thanks for your link, your website is helpful
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top