Should a thread always sleep?

[Daniel Pride]

I'm just wondering, is it necessary for a thread to sleep, lets say after every iteration of an operation or calculation it is doing?

[Ben Souther]

"indigo0086",
Please check your private messages regarding an important administrative matter.
-Ben

[Peter Chase]

Originally posted by indigo0086:
I'm just wondering, is it necessary for a thread to sleep, lets say after every iteration of an operation or calculation it is doing?

No, it's not necessary, and it would usually be wrong.

Modern operating systems have pre-emptive threading, which means that the CPU will switch between threads periodically, without the threads having to relinquish control explicitly.

If you want to do a calculation "in the background", without slowing down other processes too much, use thread priorities to achieve it. That way, if no other thread wants the CPU, your calculation gets the whole CPU; with sleeping, it won't, and time will be needlessly wasted.

[Ilja Preuss]

To add to what Peter said, if you are really in a situation where you want to tell the operating system "now would be a good time to see whether a different thread wants to do something", use Thread.yield().

[Daniel Pride]

Originally posted by Peter Chase:

If you want to do a calculation "in the background", without slowing down other processes too much, use thread priorities to achieve it. That way, if no other thread wants the CPU, your calculation gets the whole CPU; with sleeping, it won't, and time will be needlessly wasted.

If I write a simple test setting three test thread priorites, say one thread with a high priority and another with the same priority, and the last with a bit lower priority, then without yield or sleep, each thread will just continue until finished, no time slicing out.

[Nitesh Kant]

Daniel:
then without yield or sleep, each thread will just continue until finished, no time slicing out.

How do you determine that there has been no time slicing?
OS will always give you an impression that all the threads are running simultaneously.
This is *just* an "impression" that thread scheduling is "supposed" to create.
Of course unless you are having the number of processors equal to number of threads.

[Daniel Pride]

What gave me the impression was I had four threads, all of which basically did a simple count to 100, no sleeping or yielding, and the only thing that priority dictated was which one finished first, but there was no interleaving of output. Does this only indicate that short-running threads don't show signs of time slicing beyond when the thread actually starts executing.

For example, this simple Word file counter

 package wordcounter;
 
import java.io.FileReader;
import java.io.IOException;
import java.util.Scanner;
 
/**
 *
 * @author Indigo0086
 */
public class WordCounter implements Runnable
{
private String Filename;
private Scanner fileScanner;

public WordCounter(String Filename)
throws IOException
{
this.Filename = Filename;
fileScanner = new Scanner(new FileReader(Filename));
}
 
public void run()
{
int count = 0;
while(fileScanner.hasNext())
{
String[] wordLine = fileScanner.nextLine().split("[\\s]");

for(String word: wordLine)
if(!word.isEmpty())++count;
}

System.out.println(Filename + ": " + count);
}
} 

If I had 4 or 5 threads with this instruction, would they properly share time between them, or would they just execute until completion depending on priority?

[Ulf Dittmer]

A loop to 100 isn't a very good way of testing concurrency, because it's so short. The first thread may be finished before the second one ever gets started.

It's easy enough to test what this code would do, but it probably has a better chance of seeing interleaving, since there's some I/O (which takes up a loooong time compared to counting to 100).
[ May 12, 2008: Message edited by: Ulf Dittmer ]

[Daniel Pride]

Ok cool, I thought maybe it was to show which is why it was giving me the illusion of threads running sequentially rather than concurrently.
[ May 12, 2008: Message edited by: Daniel Pride ]