About Thread Priority
-
I have a problem with thread priorities, the scenario is shown as the following. A thread of "Normal" priority(Thread-A) is running, and do AutoResetEvent.WaitOne() after it has started another thread of "Highest" priority (Thread-B). Thread-B will do AutoResetEvent.Set() in the middle of it process. As I have imagined, Thread-A will not move on until Thread-B has finished completely. But to my surprise, the Thread-A may soon move on if Thread-B does Set(). Why the thread with the highest priority won't finish before threads of low priority move on. Thank you.
-
I have a problem with thread priorities, the scenario is shown as the following. A thread of "Normal" priority(Thread-A) is running, and do AutoResetEvent.WaitOne() after it has started another thread of "Highest" priority (Thread-B). Thread-B will do AutoResetEvent.Set() in the middle of it process. As I have imagined, Thread-A will not move on until Thread-B has finished completely. But to my surprise, the Thread-A may soon move on if Thread-B does Set(). Why the thread with the highest priority won't finish before threads of low priority move on. Thank you.
Thread priority gives you absolutely no control in which order threads are executed. It's just an indicator that if the processor is fully used that one thread gets more of it than another thread. It might even occur that a low priority thread can finish before a high priority thread just because it makes less calculations. So in your example it's correct behaviour that both threads run parallel - only that Thread-B gets a bit more cpu power. I would even go so far that on dual core processors (assuming no other threads/processes are running beside these two) that the priority would not have any effect at all. If you want Thread-A to run after Thread-B has finished then Thread-B should call Set() at its very end and not somewhere in the middle.
-
Thread priority gives you absolutely no control in which order threads are executed. It's just an indicator that if the processor is fully used that one thread gets more of it than another thread. It might even occur that a low priority thread can finish before a high priority thread just because it makes less calculations. So in your example it's correct behaviour that both threads run parallel - only that Thread-B gets a bit more cpu power. I would even go so far that on dual core processors (assuming no other threads/processes are running beside these two) that the priority would not have any effect at all. If you want Thread-A to run after Thread-B has finished then Thread-B should call Set() at its very end and not somewhere in the middle.
Robert Rohde wrote:
If you want Thread-A to run after Thread-B has finished then Thread-B should call Set() at its very end and not somewhere in the middle.
I imagined that Windows will work in someway like the behavior of some embedded OS. Well, it seems that I am wrong. I will reconsider the constructure of program. Thank you very much.
-
Robert Rohde wrote:
If you want Thread-A to run after Thread-B has finished then Thread-B should call Set() at its very end and not somewhere in the middle.
I imagined that Windows will work in someway like the behavior of some embedded OS. Well, it seems that I am wrong. I will reconsider the constructure of program. Thank you very much.
Well it is exactly the same behaviour as the process priority you can set via task manager. If you have a long cpu consuming process (like packing your C harddrive :-D) which you set to high you can still fire up Calc, calculate something and shut it down - all while a higher priority process is running paralell. Surely it will behave very slow but it still works.
-
Well it is exactly the same behaviour as the process priority you can set via task manager. If you have a long cpu consuming process (like packing your C harddrive :-D) which you set to high you can still fire up Calc, calculate something and shut it down - all while a higher priority process is running paralell. Surely it will behave very slow but it still works.
-
Robert Rohde wrote:
If you want Thread-A to run after Thread-B has finished then Thread-B should call Set() at its very end and not somewhere in the middle.
I imagined that Windows will work in someway like the behavior of some embedded OS. Well, it seems that I am wrong. I will reconsider the constructure of program. Thank you very much.
Even if priority defined the sequence of execution, you still are not guaranteed that the high-priority thread would come to completion after ending the process in the lower priority thread. The reason is that each thread is given a set amount of time to execute. Once that time expires the kernel moves onto the next thread, and so on. Priority defines how long a task will sit in the queue before it gets to run once again. That is why setting a thread to too high of a priority is dangerous. If you have a very tight loop in a thread running at the same level as the OS, you would remain up in the high-eschelon and run more than that OS would. This gets even hairier if you are doing an interupt specific task (printing, IO, tcpip calls, etc.) since each time you do an interrupt, you get into an even different queue and have to wait for other tasks to complete as well as your interrupt driven task before you get to execute once again. I suggest doing searches on OS Queue Theory to get a better understanding of queue management. This is OS 101 and operates like this, at a basic level, in any multi-threaded environment. There are entire schools of thread management to determine the most efficient queue management algorithms to make every task run transparent to the thread management while maintaining excellant performance on high priority threads.
-
Even if priority defined the sequence of execution, you still are not guaranteed that the high-priority thread would come to completion after ending the process in the lower priority thread. The reason is that each thread is given a set amount of time to execute. Once that time expires the kernel moves onto the next thread, and so on. Priority defines how long a task will sit in the queue before it gets to run once again. That is why setting a thread to too high of a priority is dangerous. If you have a very tight loop in a thread running at the same level as the OS, you would remain up in the high-eschelon and run more than that OS would. This gets even hairier if you are doing an interupt specific task (printing, IO, tcpip calls, etc.) since each time you do an interrupt, you get into an even different queue and have to wait for other tasks to complete as well as your interrupt driven task before you get to execute once again. I suggest doing searches on OS Queue Theory to get a better understanding of queue management. This is OS 101 and operates like this, at a basic level, in any multi-threaded environment. There are entire schools of thread management to determine the most efficient queue management algorithms to make every task run transparent to the thread management while maintaining excellant performance on high priority threads.
-
You're welcome. IBM's Big Blue was the 'research project' for the queue technology in MVS. You may find researching the chess algorithms for finding the next move. This is the similar approach for determine 'which is the next thread' when processing multi-thread environment.