> You would have to leave priority gaps between all of the user > tasks so that there are empty priority slots into which you can > elevate tasks temporarily.That would be one way for sure. I think there could be others too. Just thinking off the top of my head.....maybe temporarily swapping the priorities of the two offending tasks, then swapping them back when the inversion has been rectified? This would prevent the need to leave holes. I'm sure there are also more fancy ways, maybe temporarily removing a task so another task can take its priority, then bringing it back when the inversion has been rectified, etc.> Other than that, I don't see why it > couldn't be done. OTOH, uC/OS is typically used on fairly > small projects where priority inversion can be avoided by > design rather than worked-around at run-time.Agreed. Contrary to many texts, priority inheritance does not fix priority inversion - it is only useful to minimise its effect - and only then on the assumption that your tasks are designed with this minimisation in mind. Therefore you should not rely on it in your design. If you have priority inversion then it is indicative of there (possibly) being something wrong in your design. -- Regards, Richard. + http://www.FreeRTOS.org 13 official architecture ports, 1000 downloads per week. + http://www.SafeRTOS.com Certified by T�V as meeting the requirements for safety related systems.
Design of uC/OS (uCOS-II) kernel
Started by ●October 14, 2007
Reply by ●October 14, 20072007-10-14
Reply by ●October 14, 20072007-10-14
"karthikbalaguru" <karthikbalaguru79@gmail.com> wrote in message news:1192378446.342351.304270@i38g2000prf.googlegroups.com...> On Oct 14, 8:56 pm, "FreeRTOS.org" <noe...@address.com> wrote: >> > " In a preemptive priority based RTOS, priority inversion problem is >> > among the major sources of deadline violations. Priority inheritance >> > protocol is one of the approaches to reduce priority inversion. >> >> As others have already said, the best way to avoid priority inheritance >> is >> to not design it into your system in the first place. Having said that: >> >> > Unfortunately, RTOS like uC/OS can't support priority inheritance >> > protocol since it does not allow kernel to have multiple tasks at the >> > same priority. " >> >> As far as I know, this statement is just plain wrong. > > How can you call that as wrong ?See my reply to Grant Edwards.> > I think, that is True :(Why did you ask the question then?> > Kindly refer the Abstract present in the below link that has those > lines - > http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/wstfes/2003/1937/00/1937toc.xml&DOI=10.1109/WSTFES.2003.1201367 > > I think, It must be True :( !!Ah - "I read it on the internet, therefore it must be true". One of the newspapers in the UK once famously had a headline stating "Freddie Starr ate my hamster". Weird thing was, it turned out not to be true. http://en.wikipedia.org/wiki/Freddie_Starr -- Regards, Richard. + http://www.FreeRTOS.org 13 official architecture ports, 1000 downloads per week. + http://www.SafeRTOS.com Certified by T�V as meeting the requirements for safety related systems.
Reply by ●October 14, 20072007-10-14
On Sun, 14 Oct 2007 00:15:09 -0700, karthikbalaguru wrote:> Hi, > > I got an interesting information from internet and i have some queries > based on it as it is really strange/unbeleivable . > > " In a preemptive priority based RTOS, priority inversion problem is > among the major sources of deadline violations. Priority inheritance > protocol is one of the approaches to reduce priority inversion. > Unfortunately, RTOS like uC/OS can't support priority inheritance > protocol since it does not allow kernel to have multiple tasks at the > same priority. " > > Is it true that uC/OS does not support multiple tasks of same > priority ? > Any specific reason for such a design of uC/OS kernel ? >Originally it was designed so that the task ID _was_ the priority; this makes the OS design much simpler, because the kernel doesn't need to check for priority, it just needs to go through it's list in a for loop on the task ID. Later versions allow you to change a task's priority, but I don't know if the priorities still need to be unique. I vaguely remember reading or hearing that you can still implement a form of priority inheritance (search for it), but as has been noted you can also just design your software so that it's not an issue. I have _never_ written code that makes two separate tasks pend on one resource -- I've always written a server task for that resource, and avoided the whole resource locking/priority inversion issue. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply by ●October 14, 20072007-10-14
Chris Hills wrote:>> Mucos is a toy. > > Certainly not.I looked at mucos at one time, and it seemed to be insufficient. To me, the whole point of using an OS is that the OS core takes care of many different things. Mucos does not have much to offer. Mucos's main idea is not really an OS, but a big interrupt controller implemented in the software. This approach is very simple and efficient although it has many limitations.> >> It is not a real OS, but a bare minimum. > > It IS a real OS. Though as you point out a minimal one. At the other > end you have things like Vista which many of us would say has many many > things not really needed by an OS.Ok, here are the things that I routinely use which mucos doesn't provide: 1. Multiple waiting. 2. Hardware abstraction layer concept. Drivers. 3. Priority elevation mechanism. 4. Timer based scheduling for non-realtime tasks. 5. Multicore scheduling. 6. Mucos has the peculiar API in C. I prefer simpler object oriented API in C++. 7. Mucos is not abstracted from compiler and hardware. 8. Memory protection and virtual memory. So, I would like something smaller then the already mentioned Vista, but bigger then mucos. Since not much is available in this category, we developed our own RTOS. So far so good. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●October 14, 20072007-10-14
Tim Wescott wrote:> > I have _never_ written code that makes two separate tasks pend on one > resource -- I've always written a server task for that resource, and > avoided the whole resource locking/priority inversion issue.Client/server is a pretty heavy weight solution which has many problems, too. So you have to maintain a list of the requests to the server with the priorities for each request. And the server has to parse this list to fetch the request with the current highest priority. The access to the list has to be atomic; thus there should be a mutex protecting the list. How do you avoid the priority inversion regarding that mutex? Is it done by the OS core function? (hello mucos). What if the list of the requests is overflown? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●October 14, 20072007-10-14
On 2007-10-14, Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote:>>> Mucos is a toy. >> >> Certainly not. > > I looked at mucos at one time, and it seemed to be > insufficient.It is quite sufficient for the intended uses.> To me, the whole point of using an OS is that the OS core > takes care of many different things. Mucos does not have much > to offer. Mucos's main idea is not really an OS, but a big > interrupt controller implemented in the software.It is not a "big interrupt controller implemented in software" -- whatever that's supposed to mean. It's a small multitasking kernel with a bitmapped scheduler, timers, semaphores, etc. uC/OS doesn't even attempt to deal with interrupt controller functionality.>>> It is not a real OS, but a bare minimum. >> >> It IS a real OS. Though as you point out a minimal one. At >> the other end you have things like Vista which many of us >> would say has many many things not really needed by an OS. > > Ok, here are the things that I routinely use which mucos > doesn't provide: > > 1. Multiple waiting. > 2. Hardware abstraction layer concept. Drivers. > 3. Priority elevation mechanism. > 4. Timer based scheduling for non-realtime tasks. > 5. Multicore scheduling. > 6. Mucos has the peculiar API in C. I prefer simpler object oriented API in C++. > 7. Mucos is not abstracted from compiler and hardware. > 8. Memory protection and virtual memory.That's fine, but I _don't_ use or need those features. I don't have the rom space, the ram space, or the CPU cycles required for those features.> So, I would like something smaller then the already mentioned > Vista, but bigger then mucos.Then pick something smaller than Vista and larger than uC/OS. Pick vxWorks, or eCos, or any number of other RTOSes that meet your requirements. You've no reason for posting ignorant and derogatory things about a fine product just becase it doesn't meet your requirements. uC/OS wasn't intended to meet requirements like yours -- and that's a good thing, because then it wouldn't meet the requirements of the customers who use it.> Since not much is available in this category, we developed our > own RTOS. So far so good.Good for you. Why the need to disparage the work of others? There are other people in the world beside you, with project needs that differ from yours. -- Grant Edwards grante Yow! Oh, I get it!! "The at BEACH goes on," huh, visi.com SONNY??
Reply by ●October 14, 20072007-10-14
Vladimir Vassilevsky wrote:> > > Chris Hills wrote: > > >>> Mucos is a toy. >> >> Certainly not. > > I looked at mucos at one time, and it seemed to be insufficient. To me, > the whole point of using an OS is that the OS core takes care of many > different things. Mucos does not have much to offer. > Mucos's main idea is not really an OS, but a big interrupt controller > implemented in the software. This approach is very simple and efficient > although it has many limitations. > >> >>> It is not a real OS, but a bare minimum. >> >> It IS a real OS. Though as you point out a minimal one. At the other >> end you have things like Vista which many of us would say has many >> many things not really needed by an OS. > > Ok, here are the things that I routinely use which mucos doesn't provide: > > 1. Multiple waiting. > 2. Hardware abstraction layer concept. Drivers. > 3. Priority elevation mechanism. > 4. Timer based scheduling for non-realtime tasks. > 5. Multicore scheduling. > 6. Mucos has the peculiar API in C. I prefer simpler object oriented API > in C++. > 7. Mucos is not abstracted from compiler and hardware. > 8. Memory protection and virtual memory. > > So, I would like something smaller then the already mentioned Vista, but > bigger then mucos.There are lots of alternatives, however most of them are designed for embedded systems where cost is a major factor and thus don't support multi-core scheduling (the systems they run on are typically not multi-core). However, Linux provides most of what you want and there are several approaches to providing "real time" functionality in it. That might meet all of your listed requirements except the object oriented API, but you could write suitable wrappers for the interfaces you need.> Since not much is available in this category, we > developed our own RTOS. So far so good.OK, but this is rarely a good alternative in the long run. Maintenance costs and conversions costs if you change processor architecture tend to swamp the cost of a commercial RTOS. -- - Stephen Fuld (e-mail address disguised to prevent spam)
Reply by ●October 15, 20072007-10-15
On Sun, 14 Oct 2007 16:28:08 -0000, Grant Edwards <grante@visi.com> wrote in comp.arch.embedded:> On 2007-10-14, FreeRTOS.org <noemal@address.com> wrote: > > >> Unfortunately, RTOS like uC/OS can't support priority > >> inheritance protocol since it does not allow kernel to have > >> multiple tasks at the same priority. " > > > > As far as I know, this statement is just plain wrong. I don't > > know whether uC/OS does or does not support priority > > inheritance, but I don't see why only having one task at each > > priority would prevent its use, with some care. > > You would have to leave priority gaps between all of the user > tasks so that there are empty priority slots into which you can > elevate tasks temporarily. Other than that, I don't see why it > couldn't be done. OTOH, uC/OS is typically used on fairly > small projects where priority inversion can be avoided by > design rather than worked-around at run-time.I have no idea why you think, quite incorrectly, that you have to leave priority gaps between all tasks to implement priority inheritance. I certainly never did, and I have priority inheritance in a pre-emptive multitasking RTOS working just fine without them. Have you ever implemented an RTOS? If you have, and think you know of some problem I have missed, I'd like to hear about it. Obviously, despite working in the field for years, some of my products are going to suddenly start missing their deadlines due to priority inversion any time now. The harder one to avoid, if you allow tasks to acquire more than one locking object at the same time, is priority deadlock. If you can run an RTOS that disallows this, priority inheritance is a snap, and with no empty slots needed. The low-level details are quite simple. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by ●October 15, 20072007-10-15
On Sun, 14 Oct 2007 16:39:47 GMT, "FreeRTOS.org" <noemal@address.com> wrote in comp.arch.embedded:> > You would have to leave priority gaps between all of the user > > tasks so that there are empty priority slots into which you can > > elevate tasks temporarily. > > That would be one way for sure. I think there could be others too. Just > thinking off the top of my head.....maybe temporarily swapping the > priorities of the two offending tasks, then swapping them back when the > inversion has been rectified? This would prevent the need to leave holes. > I'm sure there are also more fancy ways, maybe temporarily removing a task > so another task can take its priority, then bringing it back when the > inversion has been rectified, etc.If you want to talk about the mechanics, it is not too difficult without leaving any gaps. In the task control block for each task, you have two entries for priority, "real" priority (whether it is fixed or you allow priorities to be changed at run-time) and "current" priority. "current" priority is ordinarily the same value as the "real" priority. That only changes when a task possessing a locking object, such as a mutex, is pre-empted one or more times by higher priority tasks, until one of the pre-empters tries to acquire the same mutex. At that time, the lower priority task possessing the mutex has its "current" priority set to that of the new higher priority requester. Since the requester is blocked, pending on the mutex, it does not appear on the ready task list, so it does not contend with the elevated possessor on that list, which is all that matters to the scheduler.> > Other than that, I don't see why it > > couldn't be done. OTOH, uC/OS is typically used on fairly > > small projects where priority inversion can be avoided by > > design rather than worked-around at run-time.I am absolutely positive that all priority inversions could be avoided in the design phase for any possible system. Having a server task for each shared resource is one method. What I am not sure of, and in fact I seriously doubt, that all systems could meet all their timing deadlines in all circumstances with such a design.> Agreed. Contrary to many texts, priority inheritance does not fix priority > inversion - it is only useful to minimise its effect - and only then on the > assumption that your tasks are designed with this minimisation in mind. > Therefore you should not rely on it in your design. If you have priority > inversion then it is indicative of there (possibly) being something wrong in > your design.I agree that any text that says priority inheritance "fixes" priority inversion is just plain wrong, and agree that the best one can do is to minimize its effect. And I also agree that the degree of minimization an RTOS can provide is limited by the design of the tasks. As in all other aspects of real time code, the programmers of tasks that might use a mutex or other locking mechanism must know what they are doing, and the code must be inspected by competent reviewers. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by ●October 15, 20072007-10-15
On Sun, 14 Oct 2007 16:21:14 -0000, Grant Edwards <grante@visi.com> wrote in comp.arch.embedded:> On 2007-10-14, Paul Keinanen <keinanen@sci.fi> wrote: > > >>Is it true that uC/OS does not support multiple tasks of same > >>priority? > > Yes. > > >>Any specific reason for such a design of uC/OS kernel? > > > > When you have two or more tasks at the same priority level, > > you usually would have to run some kind of round robin > > scheduling between these. > > That's often what is done, but it's not really required. You > can just pick one of the tasks and run it until it blocks. > > > In many simple kernels, the priority levels are fixed (e.g. > > the order in which they were created at compile or startup > > time), so the task list is always scanned in the same order > > with a strict sequence and there is no way to boost > > temporarily the priority of a single task (as needed by some > > priority avoidance protocols). > > uC/OS-II uses a bitmap scheduler. Each task is represented as > a single bit in a set of bits. When a task is runnable the bit > is set. The highest priority task is then simply the one > corresponding to the most significant bit in the set. This > mechanism is very fast and compact. However, it also means it > isn't possible to have two tasks at the same priority. There's > no technical reason why a task's priority can't be temporarily > boosted when using a bitmap scheduler, it just can't be boosted > to a priority level that's already in use.It is quite possible to use a bitmap scheduler and allow priority inheritance. I know, I've done it. It's quite simple. Here is a typical scenario: 1. Low priority task L acquires a mutex. 2. High priority task H preempts L (with possible other intermediate preemptions in between), and tries to acquire the same mutex. Task H is now blocked, and task L is promoted to the priority of task H. Since task H is now not ready, its bit in the ready bitmap is not needed. It can refer to task L, no problem. There's other bookkeeping involved, but it's really not difficult.> > Some priority inversion avoidance system might be useful in > > large systems with libraries form multiple vendors in which > > you have no control what internal resources each library is > > locking, but in small systems using some very simple RT > > kernels, I really do not see any need for any priority > > inversion avoidance protocol. > > Agreed.-- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html