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.
Hi, I think, it might not be a good idea to volatile RTX's rule(s). When I need os_dly_wait and os_itv_wait in the same task, I create a new task where I call os_dly_wait instead of calling it directly. This task sets an event or sends a message, when the time has expired.
I think you mean, "violate RTX's rule(s)" ?
Of course, if anything thells you, "do not do this" and you go ahead and do it, then you are obviously asking for trouble!
www.antronics.co.uk/.../dilbert_dont_touch.gif
Well, Andy, what bothered me was that the specifications don't say anything about the system waking up the culprit task at an unexpected moment. In addition, this self correcting behavior takes some time to regulate itself - I am not sure this is what mechanical systems need. But my biggest concerns is that this behavior is implemented at the first place: Fine, a deadline was missed - why wake-up the task retroactively? why not wait for the next opportunity?
I think you mean, "violate RTX's rule(s)" ? for sure ;-)
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...?