[ACCEPTED]-Is "while (true)" usually used for a permanent thread?-multithreading

Yep, that's what you do.

But typically it's 3 like:

bool keepRunning = true;

...

while(keepRunning){
}

Because sometimes you may like to have 2 someone/something else to have the ability 1 to stop you.

To elaborate a bit more, if a thread is 13 sleeping, when the OS comes along to activate 12 the thread, it will just check to see if 11 it's still sleeping and if so, then just 10 yield its timeslice.

If you leave out the 9 Sleep and do something like

while (true)
{
    if (workAvailable)
        {
        doWork();       
        }
}

then even if 8 workAvailable is false it will keep spinning 7 until the OS stops it, taking up its entire 6 slice doing nothing. Obviously that's a 5 little more inefficient.

You can get even 4 more complex as needed with mutexes, semaphores 3 and whatnot, as mentioned above, but things 2 get complex quickly with those, so you might 1 want to use them to solve a particular problem.

Additionally You can use System.Threading.Timer. In this case, we 2 don't have to use the Sleep method. Simple 1 example:

public sealed class TimerTask
{
    private Timer _timer;
    private int _period;

    public TimerTask(int period)
    {
        _period = period;
        _timer = new Timer(new TimerCallback(Run), "Hello ....", Timeout.Infinite, period);
    }

    public void Start()
    {
        _timer.Change(0, _period);
    }

    public void Stop()
    {
        _timer.Change(Timeout.Infinite, Timeout.Infinite);
    }

    private void Run(Object param)
    {
        Console.WriteLine(param.ToString());
    }
}

Use:

public static class Program
{
    [STAThread]
    static void Main(String[] args)
    {
        TimerTask task = new TimerTask(1000);
        Console.WriteLine("Timer start.");
        task.Start();
        Console.ReadLine();
        Console.WriteLine("Timer stop.");
        task.Stop();
        Console.ReadLine();
        Console.WriteLine("Timer start.");
        task.Start();
        Console.ReadLine();
        Console.WriteLine("Timer stop.");
        task.Stop();
        Console.ReadLine();
    }
}

Console output:

Timer start.
Hello ....
Hello ....
Hello ....

Timer stop.

Timer start.
Hello ....
Hello ....

Timer stop.

Ideally you want the thread to be "runnable" when 23 it has work to do, and "sleeping" when 22 there is nothing to do.

This is best done 21 with objects like mutual exclusions (mutexes), semaphores 20 and condition variables, which provide mechanisms 19 for threads to wake other threads up when 18 there may be something for them to do.

Just 17 doing a timed sleep is inefficient, because 16 a short sleep means the thread wastes time 15 waking up to check if there's work to do, while 14 a long sleep means the thread might be asleep 13 while there's work to be done. Usually this 12 is not a big deal but if the code deals 11 with large volumes of requests or data things 10 don't go so well.

A basic model works like 9 this: Thread A puts objects in a queue. Thread 8 B removes an object from the queue, performs 7 an action, and repeats. If there are no 6 objects in the queue, thread B will remain 5 asleep until an object arrives.

You must 4 also be careful that threads which access 3 shared stuff avoid race conditions.

I can't give any C#-specific 2 insight, but I know that C# gives you some 1 tools to help you out.

Just as some additional info, typical none 4 ending loops use

for(;;)
{
 ...
} 

as there is no compare done 3 in the loop. When doing threads it is 2 best to check a flag if the loop to end 1 or not though.

I had the same problem and tried several 20 methods, keeping an eye on the CPU % which 19 in my case was really important. Here the 18 results:

while (true) {} //this is the worst CPU-consuming one: 30% in my case.

The above, in terms of performance, is 17 the worst (takes more CPU % than any other 16 method, 30% on my project, on my pc). Much 15 better the next one:

while (true) {thread.sleep(1);} //5% cpu, in my case

The above is good in 14 terms of CPU % (around 5% in my case), but 13 not very much elegant:

Console.Readline(); //4% cpu in my case, but for very specific projects

The above is usable 12 only in specific cases, and it's good if 11 you have a console .net application running 10 on background that will never be able to 9 capture a keypress. Still not much elegant, but 8 takes around 4% of CPU in my particular 7 case.

ManualResetEvent resetEvent = new ManualResetEvent(false);
resetEvent.WaitOne(); // WINNER: 4% cpu in my case, and very elegant also.

The above, in my opinion, is the best 6 one: elegant and low CPU consuming (4% in 5 my case). You simply wait for a resetEvent 4 that will never happen. Low CPU% on waiting, and 3 elegant. Also, you can make terminate the 2 infinite waiting by calling "resetEvent.Set()", even 1 from another thread...