Hello,
If you violate RTX's rule that you are not to mix the interval and delay timers (thus a task that needs to wake-up at a certain interval is blocked), RTX will try to fix the periodic task's schedule but waking it up sooner that expected. It might take anything between 1 and 10 cycles until the original period is restored. It is possible to call "os_itv_set" again to fix it immediately, though.
The specifications tell you not to do it!
If you ignore the specifications, and do it anyway, the resulting behaviour is undefined - which means that anything could happen...!
If you want defined behaviour, then you need to stick to the specifications!
Undefined or not, I cannot accept that a common programming mistake (that can take place in a couple of year from now, during maintenance etc.) will cause equipment to fail or to behave in an undefined manner itself. there is no warning, no indication whatsoever that something is "wrong". In anything but a real "Hello world" program, this could potentially have disastrous effects! I don't think you can simply apply the Please read the manual rule here.
<gasp_in_disbelief>
Undefined or not ...
</gasp_in_disbelief>
And assuming the sign-ness of a char in C is another (far more) common programming mistake can cause equipment to fail.
Would you suggest that we all complain to the C standards authorities about that one?
As I was trying to explain, it is not the same thing. when one writes trashy code, the compiler must not intervene in any way. I think we all agree about that. but when you are using an OS and break the rules, I think the OS is VERY MUCH in a position to take actions to prevent unexpected behavior! Are you seriously comparing the C standard to the vagaries of commercial software package?!
Undefined or not, I cannot accept that a common programming mistake (that can take place in a couple of year from now, during maintenance etc.) will cause equipment to fail or to behave in an undefined manner itself.
If that's actually true, especially the part about "cannot accept", then with all due respect I must tell you that you're in the wrong line of work. This is real work for real men, using rather sharp-edged tools. Use them incorrectly and you'll cut yourself. So don't do that, then.
You keep requesting systems which cannot generally afford any overhead to waste valuable CPU power on all kinds of run-time checking. That's just not gonna happen. There be rules, and if you can't be bothered to learn and follow them, the consequences are on you.
Hans-Bernhard - critical as ever :-)
This is real work for real men
I would have posted:
This is real work for real people.
"Are you seriously comparing the C standard to the vagaries of commercial software package?!"
No, I am talking of the skills required by the developer to read and understand the documentation. All documentation, for all parts used to build a project - And appreciate the pitfalls of undefined behaviour.
Code that relies on the undefined operation of an OS is simply TRASHY CODE!
No, I am talking of the skills required by the developer to read and understand the documentation
You start sounding like Jack Sprat (that is not necessarily an offense). Aha. I hope I don't need to tell you how complex and big these programs can become. The failure above can be introduced by someone that knows the rules and the software by heart, but there is a (asynchronous) path in the program that introduces this failure, and it is unlikely to occur very often. If and when one has expensive stuff or even lives at the tip of his/her fingers, I would like to have some guarantees that SOME safeguards are in place. Don't faint, Steve :-)
"The failure above can be introduced by someone that knows the rules and the software by heart, but there is a (asynchronous) path in the program that introduces this failure, and it is unlikely to occur very often."
Sorry Tamir, but that simply sounds like a badly designed project.
Stunned Steve,
It did not happen yet, and the project is not badly designed.
But, surely, such a person would be aware of this possibility and, therefore, take steps to ensure that it can't happen - by design...?
That's exactly right Andy - the design of the operating system in question :-)
No, the design of the OS says, "you must not do this" - so it is up to you to ensure that your application cannot do it.
eg, have a flag to tell you when you're using one type of timer, and check that flag before using the other type
Andy, I believe your latest reply is a summary of the philosophical differences between me and the rest. As stated once, "arrogance and self awareness seldom go in hand in hand". People are flawed. No matter how smart you are or think you are, you will make mistakes, some of them lurking, waiting to bite you when you least expected. How much ROM space will it cost to implement a simple test and return a error code in necessary, just to indicate "there is something wrong here and it could be dangerous"? Will it delay execution by a too a significant amount of time? How many accidents can be prevented? How many lives can be saved?
For some "normal" OS, there are checked builds - special versions of the OS that incorporates extra tests to try to catch problems in the OS and in the user applications.
For an RTOS, it can be hard to make augmented versions, since extra code will take extra time, and possibly change the balance of the application. Of course, it would be good if every single application with real-time requirements was always fast enough that there was exctra cycles to spare for run-time testing.