I know the difficulty,I also think this may be a big shock for kernel.Whatever these can’t cover up the irrationality of the sem’s(or queue’s) operation.At least we should recognize that this is a job in the future.
We need a try to solve this,and may be a small Ingenious design can solve the problem.May be we can’t find a way meanwhile.
FreeRTOS will always grow in the future,I believe someone will have a good idea for this.
At now,we just need write it on the schedule rather than omit it.
Once again,this is only suggestion of my own,may be I got into a dead end,but I just want to get the thinking about this of somebody.
You also have to consider the case where a higher priority task attempts to take the semaphore when it has already been given to a task that has not executed since obtaining the semaphore.
Yes,that’s become “Priority Inversion”.We can inherit it’s priority to active lower task to running or reset the lower task to sem’s waitlist, resend the signal to higher task.
This again proves the case for a mutex instead of a semaphore as muteces keep track of ownership and as a corollary are able to handle priority inversion (they don’t do it in a nested fashion as other RTOSs do, but for most cases, single level inheritance does the job fine).
Again, I ask you to rethink your design because by now I’m convinced that you only encounter this problem because your architecture is suboptimal to begin with. From the description of what you are doing, it seems as if your couple two tasks so tightly that you effectively eliminate all concurrency from their interaction and thus the need to have multiple tasks in the first place. Even if such a design has worked on multiple platforms and for a long time, it still appears suboptimal and wasteful of resources (to begin with, you need to maintain two tasks including their stack and scheduling footprint where one would suffice; also, the requirement to re-sequentialize the control flow via synchronization mechanisms encurs the danger of your entire spectrum of synchronization problems).
Again, I’m not arguing as it’s your design, your software and your maintenance efforts, but for well designed systems, I don’t see a real need to change the OSs behavior (at least in the 15+ years I have worked full time with FreeRTOS now, I haven’t seen a need for it).
Mutex or sem, this is not important,they have the same feature in FreeRTOS,my goal is mutual exclusion,I just use sem as mutex here,I had used mutex at earlytime.
You always talk about my code design with your 15 years of experience,but I think OS shouldn’t care how user to use it,just provide service.
Now,I want a service:many task have the same priority, fight for the same resource,have “First Come,First Service” rule.Not the service:one tasks has waited and release the resource many times,other task always wait forever,but can’t get it.
May be my technological level is very low( despite having worked with embedded platform for 10 years),but my code is need this service.
My code is running well on ucos-ii, linux and windows before,but I got error with same code when I ported it onto FreeRTOS.
Yield is only one simple code,I can add it to my code in the FreeRTOS’s ported part.But I think my design is well for my busyness, I don’t need change it.And I also think yield is not the most reasonable solution.
At least on Linux / POSIX I think it‘s possible to setup a scheduling scheme/policy very similar to FreeRTOS and you’ll probably get a similar behavior as on FreeRTOS.
BTW if you want mutual exclusion you’ll want to use a mutex. It’s not exactly the same thing a binary semaphore not supporting priority inheritance.
Just my 2ct
A fundamental property that you need to remember, especially in C programming, is that just because something seems to work, doesn’t mean it is right.
Your program structure does NOT enforce your requirements. Semaphores are NOT a ‘first come, first service’ object, but has priority as part of its operation.
I will point out that some OSs give every task a distinct priority level, and don’t allow shared priority levels so your program structure will just fail there, as you seem to NEED the round robin operation for equal priority.
If you need that service, it isn’t that hard to provide it (just add the yield after the release). Not everyone wants that behavior, and the cost to include it seems to be too high for what it gives.
