ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi all
I Am trying to do thread prioritization.I am applying SCHED_RR and SCHED_FIFO but in both the cases thread 1 is running more times than thread 2.am giving same priority to both the threads.
I Am trying to do thread prioritization.I am applying SCHED_RR and SCHED_FIFO but in both the cases thread 1 is running more times than thread 2.
Having run this code, I find that thread 2 reaches the end of the loop roughly five times as often as thread 1, which is what I would expect. What is it that makes you think that thread 1 is running more often than thread 2?
THREAD 1 New Counter Value: 1
THREAD 1 New Counter Value: 2
THREAD 1 New Counter Value: 3
THREAD 1 New Counter Value: 4
THREAD 1 New Counter Value: 5
THREAD 1 New Counter Value: 6
THREAD 1 New Counter Value: 7
THREAD 1 New Counter Value: 8
THREAD 1 New Counter Value: 9
THREAD 1 New Counter Value: 10
THREAD 1 New Counter Value: 11
THREAD 1 New Counter Value: 12
Thread 2 New Counter Value: 1
upto
Thread 2 New Counter Value: 358
THREAD 1 New Counter Value: 13
upto
THREAD 1 New Counter Value: 440
Thread 2 New Counter Value: 359
Thread 2 New Counter Value: 360
upto
Thread 2 New Counter Value: 2109
& so on
my purpose of this program is that each thread should run with the same time slice since both threads are having same priority i.e. 99
We are running this program on target board PXA 300 with real time patch. we have run this program in normal PC as well output is coming similar to that
Last edited by utkarshrawat; 05-10-2011 at 11:24 PM.
Again, you have to be careful how you are measuring this.
Since both threads are tying up the output to the terminal, you won't get a lot of real task switching going on (ie, one thread will hog the resource, and the other thread will be forced to wait, otherwise known as thread starvation). Occasionally you will see a switch, but it will be rare. Over a long enough period of time, you will see both threads get a fair go.
A better method is to do more work in each thread before sending anything to the output, so that the chances of both being in the output write at the same time are reduced.
But even just the following test shows you that it is working. The threads will still only switch rarely, but at least the redirection will give a larger sample size).
Code:
./a.out >a.txt
[and let it run for 10 seconds before killing it]
grep 'THREAD 1' a.txt | tail -1
grep 'Thread 2' a.txt | tail -1
Last edited by neonsignal; 05-10-2011 at 11:38 PM.
When you try to "observe" the behavior of threads in this way, the very fact that you are observing them completely changes their behavior. (And... thus, invalidates your measures.)
Treat thread-prioritization only "at best, as a suggestion to the scheduler." Whenever two threads happen to be, for whatever reason, "simultaneously available for dispatching" (and at no other time...), the thread-priority value comes into play. This is your chance to say, "well, sir, all things being equal... if it's quite all right with you, sir... I would prefer that you, please sir..." And then you must leave it at that.
You can never predict which thread will be dispatched "first," "next," or "more/less often." That's strictly the decision of the Scheduler, and you are obliged to assume that it really does know what it is doing.
Last edited by sundialsvcs; 05-11-2011 at 04:42 PM.
I have a PXA300 board in which iam running my application I am using mutex , semaphore for the proper scheduling & time optimization ,some how I have achieved the time optimization . But i want to further improvement in the timing ,
So I used scheduler (round robin & FIFO) but it seems there is no further improvement in the timing ,Do i have to change the design of my application for the further improvement of timing. or If u can suggest me something else to do in my code .I cannot post my application here since it is huge.
It frankly seems to me that you are asking for a degree of control over "the timing" that you simply can't have.
You don't say what "improvement in the timing" would mean to you and to this application. You're going to have to be able to identify "where it hurts," and "why it hurts," and to do so in such a way that it points to an implementable solution.
Remember that the operating system's thread-and-task scheduler is not a generalized "workload scheduler" such as a high-volume/high-availability application might require to have within itself. In fact, most such applications that I have seen are single-threaded.
Last edited by sundialsvcs; 06-04-2011 at 12:00 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.