Giving control to thread with always lower priority

This is a general question. consider a scenario wherein we have a some threads with开发者_StackOverflow社区 varying degree of priorities. now in such scenario the thread with lowest priority will never get control of the resources, since share will always go to the thread with highest priority. is there anyway in which we can bypass threads with higher priority and give resources to thread with lower priority?

The built in mechanism for this is the thread's priority. By setting a low priority on a thread you're telling the operating system that its activity is "less important", and hence if threads that are more important (have higher priority) need to run, then those threads take precedence.

If you don't want a thread to get potentially no CPU time, then it should not be a low priority thread.

If you think of how this is implemented in an operating system you will see that lower priority threads do run the difference is that they are given less total timeslices in which to execute. Low priority threads will always execute even if a system is starved for resources. The only thing you may see is that it will not run for as long as the higher priority threads get to run. If you wish to know more I would suggest looking up different methods that operating systems can use to schedule processes and threads.

If you are thinking of doing this in a programming language then simply change the thread priority so that it can make more progress every time it does run. Usually you have low priority threads to do background events that are not very time critical or you do not want the thread to take up as much time as a more important thread.

Obviously there is. Waiting. If the higher priority thread is waiting for something (might be anything—lock, data from file, user or network, timer...) it is not runnable, so next higher priority thread gets to run.

Also non-realtime priority is usually a variable number. Priority of scheduled process is decreased while being slowly increased for all processes (by or up to another tunable factor). That way if you have several threads that don't wait for anything, each time the scheduler will pick the one that was not on CPU for longest time. Also that way a thread that was waiting will be promptly scheduled when the resource becomes available, because it gathered high priority while it was waiting (this keeps user interface responsive with background process using up all CPU otherwise).

That doesn't necessarily have to be the case - it depends on the priority implementation. The way you describe it assumes that high priority threads will keep running until they complete and deprive lower priority threads from execution time.

This might be one way to implement it, but I think a fairer policy would be to have time-slice sharing instead. So the priority determines how much CPU time each thread gets, and not necessarily the order in which they will be executed.

This is the responsibility of the scheduler - Wikipedia:Scheduling