We Keep Coding

Odd c++/java multi threading performance results compared to single thread

I was struggling since 2 days to understand what is going on with c++ threadpool performance compared to a single thread, then I decided to do the same on java, this is when I noticed that the behaviour is same on c++ and java.. basically my code is simple straight forward.
package com.examples.threading
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicLong;
public class ThreadPool {
final static AtomicLong lookups = new AtomicLong(0);
final static AtomicLong totalTime = new AtomicLong(0);
public static class Task implements Runnable
{
int start = 0;
Task(int s) {
start = s;
}
#Override
public void run()
{
for (int j = start ; j < start + 3000; j++ ) {
long st = System.nanoTime();
boolean a = false;
long et = System.nanoTime();
totalTime.getAndAdd((et - st));
lookups.getAndAdd(1l);
}
}
}
public static void main(String[] args)
{
// change threads from 1 -> 100 then you will get different numbers
ExecutorService executor = Executors.newFixedThreadPool(1);
for (int i = 0; i <= 1000000; i++)
{
if (i % 3000 == 0) {
Task task = new Task(i);
executor.execute(task);
System.out.println("in time " + (totalTime.doubleValue()/lookups.doubleValue()) + " lookups: " + lookups.toString());
}
}
executor.shutdown();
while (!executor.isTerminated()) {
;
}
System.out.println("in time " + (totalTime.doubleValue()/lookups.doubleValue()) + " lookups: " + lookups.toString());
}
}
now same code when you run with different pool number say like 100 threads, the overall elapsed time will change.
one thread:
in time 36.91493612774451 lookups: 1002000
100 threads:
in time 141.47934530938124 lookups: 1002000
the question is, the code is same why the overall elapsed time is different what is exactly going on here..

You have a couple of obvious possibilities here.
One is that System.nanoTime may serialize internally, so even though each thread is making its call separately, it may internally execute those calls in sequence (and, for example, queue up calls as they come in). This is particularly likely when nanoTime directly accesses a hardware clock, such as on Windows (where it uses Windows' QueryPerformanceCounter).
Another point at which you get essentially sequential execution is your atomic variables. Even though you're using lock-free atomics, the basic fact is that each has to execute a read/modify/write as an atomic sequence. With locked variables, that's done by locking, then reading, modifying, writing, and unlocking. With lock-free, you eliminate some of the overhead in doing that, but you're still stuck with the fact that only one thread can successfully read, modify, and write a particular memory location at a given time.
In this case the only "work" each thread is doing is trivial, and the result is never used, so the optimizer can (and probably will) eliminate it entirely. So all you're really measuring is the time to read the clock and increment your variables.
To gain at least some of the speed back, you could (for one example) give thread thread its own lookups and totalTime variable. Then when all the threads finish, you can add together the values for the individual threads to get an overall total for each.
Preventing serialization of the timing is a little more difficult (to put it mildly). At least in the obvious design, each call to nanoTime directly accesses a hardware register, which (at least with most typical hardware) can only happen sequentially. It could be fixed at the hardware level (provide a high-frequency timer register that's directly readable per-core, guaranteed to be synced between cores). That's a somewhat non-trivial task, and (more importantly) most current hardware just doesn't include such a thing.
Other than that, do some meaningful work in each thread, so when you execute in multiple threads, you have something that can actually use the resources of your multiple CPUs/cores to run faster.

How to avoid threads to starve

Suppose I have a hotel with m Rooms.
Guests (Threads) come in and out the whole time.
A Room can have lots of people inside, but only one Room will have people. For example:
Guest A (wants Room 1)
Guest B (wants Room 2)
Guest C (wants Room 1)
A can go to Room 1, once all rooms are empty;
B cannot go to Room 2 yet, given that there is another room with people still inside;
C can go to Room 1, because the Room C wants is the only Room with people inside;
Given that A and C leave Room 1, B should be able to go to Room 2
The last Guest to exit a room should stop every other Guests (avoiding them to come in while he is coming out) until it leaves, so the others can continue
How can I implement this somehow the threads will not starve?
For simplicity, suppose that, once the Guest comes inside a room, it sleeps for some seconds and then get out. Here is my (wrong) implementation:
import java.util.ArrayList;
import java.util.Random;
public class Guest extends Thread {
static Rooms rooms = new Rooms(5);
int id;
Guest(int id) {
this.id = id;
}
public void run() {
rooms.join(this);
nap();
rooms.quit(this);
}
public void nap() {
try {
sleep((new Random().nextInt(4000) + 1000));
} catch (InterruptedException e) {
}
}
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 20; i++) {
Thread t = new Guest(i);
t.start();
Thread.sleep((long) new Random().nextInt(1500) + 1000);
}
}
}
class Rooms {
Room[] rooms;
int busy;
Rooms(int m) {
busy = -1;
rooms = new Room[m + 1];
for (int i = 0; i < m + 1; i++)
rooms[i] = new Room();
}
void join(Guest h) {
if (busy == -1) {
busy = (new Random().nextInt(rooms.length));
}
rooms[busy].add(h);
System.out.println("Guest " + h.id + " came inside room " + busy + " with " + rooms[busy].size() + " people");
}
void quit(Guest h) {
if (rooms[busy].size() == 1) {
setHandler(busy, h);
} else {
rooms[busy].remove(h);
System.out
.println("Guest " + h.id + " came out of room " + busy + " with " + rooms[busy].size() + " people");
}
}
synchronized void setHandler(int numQuarto, Guest ultimo) {
System.out.println("(Last) Guest " + ultimo.id + " came out of room " + busy + " with "
+ rooms[numQuarto].size() + " people");
rooms[numQuarto].remove(ultimo);
busy = -1;
}
}
class Room extends ArrayList<Guest> {
}

To do this with threads -- which is highly artificial, but I suppose it is an exercise -- you need to learn how to make a Thread wait on a condition, and how to notify one or more Threads that the condition they are waiting for may have been satisfied. Conveniently, every object has methods wait(), notify(), and notifyAll() that serve these purposes.
One important consideration with wait / notify is that you must be careful to wait on and notify the correct object. Generally, that's not the Thread you want to be affected, but rather some shared object that all threads involved rely upon for mutual synchronization. In this particular case, it looks like Guest.rooms would do nicely.
The general idea would be that in Rooms.join(), the current thread tests whether it can immediately take a room. If so, it does, and continues as now. If not, however, it invokes wait() (on the Rooms instance, which at that point is this). Whenever that wait() returns, the thread must again check whether it can immediately take the room it wants; if not, it must wait again.
The other half would be in Rooms.quit(). Whenever a thread running that method is the last one out of the room, it must reset busy to indicate that no room is occupied, and then, importantly, invoke notifyAll() to let all threads waiting at that time know that there's a chance to get a room.
You will find that you need to employ proper synchronization for this. In particular, you can invoke wait() and notifyAll() (and notify()) only while holding the monitor of the target object (it will be released for the duration of the wait, and reacquired before wait() returns). You will also need to ensure that you properly synchronize all manipulation of shared objects, however, in this case mainly the Rooms and its members, without preventing threads from proceeding when otherwise they could. In particular, be aware that threads that sleep() do not for that reason release any monitors they may hold.
The rest is up to you. I've given you rather a lot more of a hint than maybe I should, but it truly is a bit tricky to learn how to use wait / notify properly.

You can't. Based on what you've given, other mechanisms would need to be implemented which guarantee no starvation can occur. For example,
Guests (Threads) come in and out the whole time.
So, it's possible that n threads come in for Room m possibly the whole time. It's possible, too, that during that time more threads come in wanting another room. However, they cannot access the room until Room m is first emptied (which may never actually happen). This can continue for any number of rooms and threads. This is the case even if...
For simplicity, suppose that, once the Guest comes inside a room, it
sleeps for some seconds and then get out.
And that's because...
C can go to Room 1, because the Room C wants is the only Room with
people inside;
Which implies that another thread may enter an already occupied room with one or more threads with t time left to sleep. The new thread goes to sleep and won't wake up until after the previous one. While sleeping n more threads may enter the room potentially causing other threads waiting for other rooms to starve.

How can we make a thread to sleep for a infinite time in java?

Pls help me to understand how can we make a thread to sleep for a infinite time period .

I can't think of a good reason for doing this. As one of the comments noted Long.MAX_VALUE is roughly 292 billion years so probably Thread.sleep(Long.MAX_VALUE) is enough. But if you want a theoretical infinite sleep solution:
while (true) {
Thread.sleep(Long.MAX_VALUE);
}

Literally, you can't. No Java application can run for an infinite amount of time. The hardware will die first :-)
But in practice1, the following will sleep until the JVM terminates ... or the thread is interrupted.
public void freeze() throws InterruptedException {
Object obj = new Object();
synchronized (obj) {
obj.wait();
}
}
If you wanted to you could catch the exception within a while (true) loop. And doing the same with "sleep(max int)" is equivalent.
But frankly, making a thread go to sleep "for ever" is wasteful2, and probably a bad idea. I have no doubt that there will be better ways to achieve what you are really trying to do.
1 - These solutions I talk about are for when a thread needs to make itself go to sleep. If you one thread to unilaterally make a different thread go to sleep, it can't do that safely. You could use the deprecated Thread.suspend() method, but it is dangerous, and it may not be available on future Java platforms.
2 - A thread stack occupies a significant amount of memory, and it cannot be released until the thread terminates.

Thread.currentThread().join();
Will sleep until the JVM is killed.

Make it wait for a mutex or resource that will never be released. It's the deadlock principle. The better way is to make the thread to finish his code, so it will end and not be started again.
Edit:
I don't recommand an infinite loop since it's the pooling principle. It will consume a lot of resources for nothing.

You can use class CyclicBarrier from the JDK.
new CyclicBarrier(2).await();
Constructor argument is the number of threads that must invoke await method before the barrier is reached.

It's actually quite easy if you do it this way:
public static boolean timerController = false;
Timer timer = new Timer();
public TimerTask task = new TimerTask() {
public void run() {
if(timerController == false){
tracker();
t.setText("<html><br/>Day " + day + ", hour " + hour + "<br/>");
System.out.println("Hour: " + hour + " Day: " + day + " Real time seconds " + realTime + " Seconds");}
}
};
public void start() {
timer.scheduleAtFixedRate(task, 1000, 1000);
}
public void pause(){
timerController = true;
}
public void resume(){
timerController = false;
}
Make a timer object in another class, and simply start, pause, and resume with the three methods. It should "stop" when you pause the timer, and you won't need to deal with any exception handling or any try/catch statements!

Why my thread only execute once even if its in an infinite loop?

Well, my thread was running only once, so I realized I forgot to put it inside an loop, so I did, put it into an while{true} loop, but still it only repeats once.
Here is my code:
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package snake.multiplayer;
import java.util.ArrayList;
/**
*
* #author GUIAKI
*/
public class movimentacoes implements Runnable {
Jogo jogo;
ArrayList<Player> players = new ArrayList<Player>();
int qtdadePlayers;
long lastTime;
long delay;
long millis(){
return System.currentTimeMillis() % 1000;
}
public void run(){
int i;
while(true){
if(lastTime-millis()>=delay){
for(i=0;i<qtdadePlayers;i++){
players.get(i).anda();
System.out.println("Printou");
}
jogo.repaint();
//checaColisao();
lastTime=millis();
}
}
}
}
and here is where I call it:
Mov = new movimentacoes();
Mov.players.add(0,new Player(500,500,playimg.getImage(),15));
Mov.qtdadePlayers=1;
Mov.lastTime=System.currentTimeMillis() % 1000;
Mov.delay=50;
Mov.jogo=this;
Thread t1 = new Thread(Mov);
t1.start();
The most odd thing, is that if I debug the code, it runs repeatedly if I still debug it.
How can I make it keep running?

In the method:
public void run(){
the condition:
if(lastTime-millis()>=delay){
will start to get negative values once it runs more than once, so its needed to change the order:
if(millis()-lastTime>=delay){
Than it all works as it should, thanks Sotirios Delimanolis.

wont lastTime-millis() be a negative value? because millis is time in the future to lastTime
change it to millis()-lastTime

Your code seems ok, there are 2 things that could happen:
1 - for some reasong the thread throws an exception and that would abort the thread
2 - you are running some old version of the compiled code (this could be because the debug version could be in a different folder than the release)
Try to clean and rebuild your project.

What you want to do is to periodically call a Runnable and execute it. You can have a thread run infinitely in a loop and check the time, however this model wastes a lot of CPU time by asking for the time (actually 100% CPU) and even if you include a Thread.sleep() there is no guarantee that it is woken up on time. A much better way is to schedule a task at a fixed rate. Java can do this with the ScheduledExecutorService.
In your case the run method becomes:
public void run(){
for(int i=0;i<qtdadePlayers;i++){
players.get(i).anda();
System.out.println("Printou");
}
jogo.repaint();
}
And then you need to schedule it in an Executor like this:
final ScheduledExecutorService executor = Executors.newScheduledThreadPool(NUM_THREADS); // 1 threads is probably enough for your case
// ...
executor.scheduleAtFixedRate(new Movimentacoes(), 0, delay, TimeUnit.MILLISECONDS);
To stop the Runnable once your program terminates, you call executor.shutdown(). After this call any Runnables currently in progress will receive an interrupted status and no further calls are scheduled. The program will eventually terminate, once all currently still running Runnables have finished their run method. So in case your code takes a while, you might want to query Thread.interrupted().

What could cause a java process to get gradually decreasing share of CPU?

I have a very simple java program that prints out 1 million random numbers. In linux, I observed the %CPU that this program takes during its lifespan, it starts off at 98% then gradually decreases to 2%, thus causing the program to be very slow. What are some of the factors that might cause the program to gradually get less CPU time?
I've tried running it with nice -20 but I still see the same results.
EDIT: running the program with /usr/bin/time -v I'm seeing an unusual amount of involuntary context switches (588 voluntary vs 16478 involuntary), which suggests that the OS is letting some other higher priority process run.

It boils down to two things:
I/O is expensive, and
Depending on how you're storing the numbers as you go along, that can have an adverse effect on performance as well.
If you're mainly doing System.out.println(randInt) in a loop a million times, then that can get expensive. I/O isn't one of those things that comes for free, and writing to any output stream costs resources.

I would start by profiling via JConsole or VisualVM to see what it's actually doing when it has low CPU %. As mentioned in comments there's a high chance it's blocking, e.g. waiting for IO (user input, SQL query taking a long time, etc.)

If your application is I/O bound - for example waiting for responses from network calls, or disk read/write

If you want to try and balance everything, you should create a queue to hold numbers to print, then have one thread generate them (the producer) and the other read and print them (the consumer). This can easily be done with a LinkedBlockingQueue.
public class PrintQueueExample {
private BlockingQueue<Integer> printQueue = new LinkedBlockingQueue<Integer>();
public static void main(String[] args) throws InterruptedException {
PrinterThread thread = new PrinterThread();
thread.start();
for (int i = 0; i < 1000000; i++) {
int toPrint = ...(i) ;
printQueue.put(Integer.valueOf(toPrint));
}
thread.interrupt();
thread.join();
System.out.println("Complete");
}
private static class PrinterThread extends Thread {
#Override
public void run() {
try {
while (true) {
Integer toPrint = printQueue.take();
System.out.println(toPrint);
}
} catch (InterruptedException e) {
// Interruption comes from main, means processing numbers has stopped
// Finish remaining numbers and stop thread
List<Integer> remainingNumbers = new ArrayList<Integer>();
printQueue.drainTo(remainingNumbers);
for (Integer toPrint : remainingNumbers)
System.out.println(toPrint);
}
}
}
}
There may be a few problems with this code, but this is the gist of it.