never ending loop on a multiprocessor machine
We would like to run a thread that constantly iterates a cache ( ConcurrentHashMap) and checks for certain values.
In other words this is actually a busy endless looping thread.
Will this cause congestion ( performance downgrade) on a multiprocessor machine ( for example a strong Solaris 10 machine)?
Or will a multiprocessor machine smartly "set aside" one of it's processors for this endless looping thread?
thanks
John
[461 byte] By [
John49a] at [2007-11-26 17:55:20]
# 1
It's an interesting question, but the answer would only pertain to a particular model of a single machine.
Using a spin lock is a common solution to avoid the overhead of locking an object. But it is only valuable for a short duration. Spinning forever would be fatal.
Do you intend to use Thread.yield() periodically? Or some other method to give up control?
# 2
I guess calling Thread.yield() periodically is a good idea.
Or maybe calling Thread.sleep(1000) after every loop?
These are 2 options which will obviously slow down the looping, but i guess we will do it if this is the best practice.
But i still don't understand... If the machine has 4 processors ( for example ), why is so fatal ( performance wise ) that one thread is constantly looping?
The machine has 3 additional processors to serve other Threads.
# 3
What is today may not be tomorrow.
By designing an application that only runs well on one particular architecture you're restricting the application. Machines change constantly. When you write a "generally acceptable" module, it can port to any machine anywhere at any time (the beauty of Java.)
In any case, hogging a cpu is bad manners. There are probably other threads that could use a little compute time too.
# 4
The OS won't set aside a processor for the loop, but most modern OSes use processor affinity when deciding on which processor to place a task - ie it will try to place it on the same CPU it last used to take advantage of a hot cache etc.
Under normal operation of Solaris/linux/Windows the endless-loop thread will get preempted when its timeslice expires, so it won't hog the CPU entirely (unless the system is so lightly loaded that there's no need to preempt it). Of course it might get preempted due to actual lock contention - though if it only reads the ConcurrentHashMap that should not be the case there - but it might encounter contention elsewhere once its has found one of these special values.
Whether you should let this thread run endlessly without yield (could be a no-op on a multiprocessor anyway) or sleeping, is something that needs to be considered at the application level. How often are these special values likely to occur? How important is it to respond to these special values quickly? How important is the other work the application might want to do? It's more typical for such scanning activities to be periodic rather than run continually.
# 5
> We would like to run a thread that constantly
> iterates a cache ( ConcurrentHashMap) and checks for
> certain values.
> In other words this is actually a busy endless
> looping thread.
> Will this cause congestion ( performance downgrade)
> on a multiprocessor machine ( for example a strong
> Solaris 10 machine)?
Yes, of course an endless loop will cause congestion and performance degredation. Having dual processors has nothing to do with that. Or more precisely, it has to do with how the OS behaves in the face of such an ill-behaved piece of code.
>
> Or will a multiprocessor machine smartly "set aside"
> one of it's processors for this endless looping
> thread?
>
What would be smart about that? Is one processor better than the other?
# 6
Wow this crowd is getting hostile lately!
endless-loop != ill-behaved bad code. If there is a continuous task that can perform useful work for the application then that is a facet of the application. Would it be good trying to run on a uniprocessor? Of course not. So you run on a multi-processor - there are many many applications that will never be run on single-processor systems.
So the question is: given you have this "endless loop" will a multi-processor configuration actually handle that well? Under the right environment you might flag that endless loop with a particular scheduling class and priority and ensure the OS gives it a dedicated processor - or use processor binding if available. A general Java VM doesn't provide that. So as I explained if there is sufficient load on the system then the endless task will get preempted periodically.
