Professor Plödereder was (is?) in the ISO standardizing committee for Ada and it shows.
Great professor, great lectures. I took every lecture he offered.
My best memory is when he asked me questions in an oral exam that weren't totally foreign, but... somehow off the expected path. He never asked many questions whose answers were right in the lecture notes, always probing whether you had understood the concepts, so I assumed he was particularly demanding that day. When I came back into the room to get my grade, he told me that his TA had informed him that he was examining a different lecture than he was supposed to, and that he was quite impressed how I held myself up. The grade was accordingly chosen. :-)
EDIT to add: Not just on a committee but helped write the Ada 2012 reference with Tucker Taft and some others. Too bad they're fans of paywalled and non-FOSS work. A lot of this will disappear into ancient history because of it. Least we got a great RT book. :)
Yes, and doing the diploma thesis (or the undergraduate thesis) in his group was one of the rare opportunities to get your hands on AdaCore's compiler, not the neglected free gcc version.
This is a good amount of knowledge that I use in my day-to-day job all wound up in one place. Most excellent -- takes people years to get good at and accustomed to designing systems and software for a hard real time, safety-critical environment. We measure/characterize certain aspects of our software's performance down to the nanosecond (and more commonly, to the microsecond) ... pretty sure that's not the norm in most disciplines :). FWIW, we use Ada, a restricted version of C, and a version of C++ that's so restricted that it's really more like our restricted version C than true C++. Industry trend seems to be away from Ada and toward C, at least for non-military aerospace. We use Java, C#, Python, etc. etc. etc. for our ground-based stuff -- restrictions are only on flight software.
Too hard to find people who know ada, and more difficult to do some of the low-level things that operating systems need to do (for the same reasons that it's safer). Might not be the case for application software -- I work mostly on platform/OS software.
He covers priority inversion, a high priority task is preempted by a lower priority task. There's a similar neologism, bikeshedding, wasting time on trivial details while important matters wait.
It's not that similar at all. In priority inversion, the task of choosing the
colour of the bike shed is essential to complete the whole reactor (even if
it's unimportant which colour would that be). In bikeshedding, both tasks can
be carried out independently. Priority inversion happens when a task of high
priority waits for a low-priority task to finish, then the low-priority task
has its priority artificially and temporarily increased.
Moreover, bikeshedding is not a term from technical ground, but from
psychology. It talks about what people want instead of how computer system
works.
In Parkinson's original and fictional example, members of an organisation give disproportionate weight to trivial issues. This is not a matter of sequence or independence. With respect to similarity, I will equate priority and weight.
> In Parkinson's original and fictional example, members of an organisation give disproportionate weight to trivial issues. This is not a matter of sequence or independence.
But it's a matter of psychology of the organization members, not
a technical issue. On the other hand, priority inversion is purely technical
thing.
And then, the reactor could easily be built without bike shed finished. The
two tasks are independent. Inversion of priorities happens precisely because
the high priority task cannot be finished without the low priority task.
Thus, both the field the term operates on and the term's mechanics are
completely different.
> With respect to similarity, I will equate priority and weight.
And that's about the only aspect of the two terms that is similar. Both talk
about two objects with vastly different (nominal) importance.
Great professor, great lectures. I took every lecture he offered.
My best memory is when he asked me questions in an oral exam that weren't totally foreign, but... somehow off the expected path. He never asked many questions whose answers were right in the lecture notes, always probing whether you had understood the concepts, so I assumed he was particularly demanding that day. When I came back into the room to get my grade, he told me that his TA had informed him that he was examining a different lecture than he was supposed to, and that he was quite impressed how I held myself up. The grade was accordingly chosen. :-)