Since we are talking specifically about standard linux, this is a bit off topic, however there are scheduling concepts here that apply to any priortized system that I think are probably reasonable for this list.
Saikrishnan Krishnamurthy wrote: > Thanks Mr. Tyson, > > Your mail was very much informative. I have three real-time threads > that need to run at the same priority. I tried using the SCHED_RR by > explicitly changing the policy and the rt_priority at the start of each of the > threads. The code is something like this. > > lock_kernel(); > daemonize(); > > current->policy = SCHED_RR; > current->rt_priority = 5; > > thread_ID = current; > unlock_kernel(); > > I call schedule() at the end of each stage of processing in each > thread so that the CPU can be given to the other threads for processing. > Is this way yielding sufficient enough or do I need to do anything else. Calling schedule is not sufficient because your thread is still ready to run. In this case, all that calling schedule() will do is yield the processor to any task at the same or higher priority. This is true of any prioritized system, including RTLinux. Since you are running in the kernel which isn't preemptable with applying a patch, SCHED_RR won't buy you anything over SCHED_FIFO. In either case you will have to call schedule() for any other task to run. In user mode or with the preemptable kernel patch then calling schedule() isn't needed. > > Although my code works fine if all the three threads are run with the > SCHED_OTHER policy, it has problems only with the SCHED_RR and SCHED_FIFO > policies. The combination of calling schedule() (because a standard kernel isn't preemptable except by interrupts) and SCHED_OTHER allows other processes to run on a time-share basis. Once you switch to SCHED_RR you are running prioritized scheduling and each time schedule() is called the highest priority thread that is not sleeping will be run. Your SCHED_RR processes must sleep or lower level threads will never run. Think about what is happening. You have told the system that your SCHED_RR processes shouldn't not be preempted by any lower priority or SCHED_OTHER thread, so that is what it does. Anything other behavior would be some sort of priority inversion. > 1) Will use of semaphores between the threads be a reason for the code > hanging. (But the code works fine in SCHED_OTHER mode). This is almost certianly not the problem since semaphores will put threads to sleep allowing other threads to run and because it works with SCHED_OTHER. Though it is possible that you are getting a deadlock I epect the problem is a lack of sleeping on the part of your SCHED_RR threads. > > 2) Can networking stuffs like reading and writing to sockets be allowed > under this policy. I don't know the answer to this question. I would ask that question on the linux-kernel list. Since the policy of the kernel is to block everything in critical sections the kernel shouldn't suffer from dead-locks and priority inversion, assuming you don't find a lurking bug. Given that, I would expect it to work, but can't be certain. General question: Are you sure you need to run the threads in the kernel? Why not make it a user level thread with a device driver for accessing what you need from the kernel? Since you are not using RTLinux I have to assume that your required latencies aren't too tough and moving to user space won't really hurt that anyway Can you define what your realtime requirements are? What is your worst case allowable latency? How does the system fail if you miss this requirement? How much CPU time does this system need each time it runs? If we go much further into the details of your system rather than talking about scheduling in general we should probably take this off the list into private email. > thanks, > Sai. Cheers! Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Military Systems Division [EMAIL PROTECTED] Robots for the Real World 603-532-6900 ext 206 http://www.irobot.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
