Java Threads

Thread view:

Aki Tuomi - 22 Apr 2006 22:00 GMT

I am running a java program on a multiprocessor environment, and I am
having real tough time getting it to make use of the second CPU there.

The program is using fixed ThreadPool of 100 workers for the threads. Is
there some magic option I need to enable the use of second CPU?

Aki Tuomi

Reply to this Message

Knute Johnson - 22 Apr 2006 22:13 GMT

> I am running a java program on a multiprocessor environment, and I am
> having real tough time getting it to make use of the second CPU there.
[quoted text clipped - 3 lines]
>
> Aki Tuomi

Windows or Linux?

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Aki Tuomi - 22 Apr 2006 22:36 GMT

Knute Johnson kirjoitti:

>> I am running a java program on a multiprocessor environment, and I am
>> having real tough time getting it to make use of the second CPU there.
[quoted text clipped - 5 lines]
>
> Windows or Linux?

Linux

Aki Tuomi

Reply to this Message

Aki Tuomi - 22 Apr 2006 22:42 GMT

Aki Tuomi kirjoitti:

> Knute Johnson kirjoitti:
>>> I am running a java program on a multiprocessor environment, and I am
[quoted text clipped - 9 lines]
>
> Aki Tuomi

$ java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)

Reply to this Message

Knute Johnson - 22 Apr 2006 23:08 GMT

> Aki Tuomi kirjoitti:
>> Knute Johnson kirjoitti:
[quoted text clipped - 15 lines]
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)

Aki:

I've not used Java on a multi-processor or core computer under Linux.
If you are running the multi-processor kernel I would think it would be
automatic. It is under Windows anyway.

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Aki Tuomi - 22 Apr 2006 23:40 GMT

Knute Johnson kirjoitti:

>> Aki Tuomi kirjoitti:
>>> Knute Johnson kirjoitti:
[quoted text clipped - 22 lines]
> you are running the multi-processor kernel I would think it would be
> automatic. It is under Windows anyway.

Well, it seems not to be automatic. It is only using the other CPU.

Aki Tuomi

Reply to this Message

Patricia Shanahan - 23 Apr 2006 00:31 GMT

> I am running a java program on a multiprocessor environment, and I am
> having real tough time getting it to make use of the second CPU there.
[quoted text clipped - 3 lines]
>
> Aki Tuomi

There are two explanations for this effect:

1. Your job is being externally constrained from using more than one CPU.

2. There is something in the structure of your program that prevents
parallelism among the threads. For example, there could be
over-synchronization.

Do you have a really simple test case, with no synchronization?

If you have problem #1, it will also use only one processor. If you have
problem #2, a very simple program with two compute-bound threads will
use two processors.

Patricia

Reply to this Message

James - 23 Apr 2006 08:45 GMT

You could try the '-server' option just to be sure.

Reply to this Message

Aki Tuomi - 23 Apr 2006 10:09 GMT

Patricia Shanahan kirjoitti:

>> I am running a java program on a multiprocessor environment, and I am
>> having real tough time getting it to make use of the second CPU there.
[quoted text clipped - 19 lines]
>
> Patricia

Well I dunno if the code would help, but here is a link to it. I tried
using the -server option with -Xms2g -Xmx2g. Doesn't do much good.

I am not very familiar with threads, altough I have tried reading a lot
of it. Just very complex issue, I think...

http://www.cs.uta.fi/~at75972/Pattern/

Aki Tuomi

Reply to this Message

Chris Uppal - 23 Apr 2006 10:44 GMT

> Well I dunno if the code would help, but here is a link to it. I tried
> using the -server option with -Xms2g -Xmx2g. Doesn't do much good.

I think by "a really simple test case" Patricia meant something like
(untested):

public class Test
implements Runnable
{
private volatile int m_counter;

public void
run()
{
for (;;)
for (int i = 0; i < 1000000; i++)
m_counter++;
}

public static void
main(String[] args)
{
Test test1 = new Test();
Test test2 = new Test();
Thread thread1 = new Thread(test1);
Thread thread2 = new Thread(test2);
thread1.start(); thread1.start();
thread1.join(); thread1.join();
if (test1.m_counter == thread2.m_counter)
System.out.println("Don't care, this is just to fool the
optimiser");
}
}

If you run that, does it max-out both processors, or only one of them ?

-- chris

Reply to this Message

Aki Tuomi - 23 Apr 2006 11:00 GMT

Chris Uppal kirjoitti:

>> Well I dunno if the code would help, but here is a link to it. I tried
>> using the -server option with -Xms2g -Xmx2g. Doesn't do much good.
[quoted text clipped - 33 lines]
>
> -- chris

After fixing few typos and running it, yes, it does max out both CPU's.

Aki Tuomi

Reply to this Message

Patricia Shanahan - 23 Apr 2006 15:59 GMT

> Chris Uppal kirjoitti:
>
[quoted text clipped - 3 lines]
>>I think by "a really simple test case" Patricia meant something like
>>(untested):

...

Yes, the deleted code is just the sort of thing I meant.

> After fixing few typos and running it, yes, it does max out both CPU's.

Good. That clarifies things. If running the test program maxes out both
CPU's, and running your real program the same way doesn't, the problem
is a bug in your program.

You are looking for something that forces the threads to run one after
the other, rather than in parallel. It could be something as simple as
calling a thread's run() rather than start(). It could be some
synchronization that affects the most CPU intensive part of the code. It
could be a logical problem involving wait/notify.

Patricia

Reply to this Message

Chris Uppal - 26 Apr 2006 10:24 GMT

> After fixing few typos and running it, yes, it does max out both CPU's.

I took a quick look at the code you linked to earlier. I'm a bit puzzled.
There's nothing obvious that you are doing which would cause that effect (for
anyone who's interested, Aki's using the new java.util.concurrent package and
between that and the fact that his algorithms work on independent sets of
objects, there's very little need for explicit synchronisation).

One thing that did strike me as worth changing, although I have no idea how it
could affect this problem, is the way that you poll waiting for the list of
tasks to complete. Two much better ways would be:

1) Use awaitTermination() on your thread pool to wait for everything to
complete.

2) Use the semantics of Future objects. If you just loop down your list of
Futures (miscalled "threads" in your code), using get() on each one, then you
you'll be blocked whenever necessary, and won't reach the end of the List until
all the Future tasks have finished.

-- chris

Reply to this Message

Java Threads

Free Magazines