Tuesday, July 11, 2006
[Late] Weekend Readings, Meaningful Coincidences and Some Real Work
Another somewhat interesting paper was "Prepare Your Mind for Learning", Communications of ACM, September 2005. I loved the concept of metacognitive miscalibration, somewhat less the examples. The suggestions were all good but not very original. I'd like to link this with the concept of filtering (see the bottom of one of my old posts). For some reason or another :-)), that reminds me of some virulent comments :-) on my previous post on test first :-).
Another somewhat interesting paper was "Achieving Scalability in Real-Time Systems", IEEE Computer, May 2006. The authors mentioned a wait-free mechanism for concurrent read/write (Cyclical Asynchronous Buffers), and got me interested enough to dig further. There is even a working implementation of CABs on the E.R.I.K.A. website at Scuola Superiore Sant'Anna (the author is also from there). Well, it's hard not to miss OOP when you read that C code, but anyway, that concept reminds me an interesting pattern (sharing 90% of the underlying idea; that's what makes it a pattern :-), "Resource Exchanger: A Behavioral Pattern for Low-Overhead Concurrent Resource Management", in "Pattern Languages of Program Design Vol. 2".
Interesting coincidence. I teach that pattern, among others, in a course on OOP/OOD for embedded systems. In these days, I'm also working on some teaching materials for embedded systems. I'm extending my "Win32 System Programming" course with a lot of stuff on Windows CE, which has been a constant theme for me in the latest months. It's funny how many things we routinely teach as "good programming style" in C++ makes much more sense for embedded systems (which, after all, should not surprise anybody :-). For instance, under CE the compiler is actually moving static const data to a read-only memory segment (as many "embedded" compilers do). That makes the idea of casting away const on a const reference to a const object dangerous enough :-) to justify the unspecified behaviour label in the ANSI/ISO standard :-), and is indeed my standard explanation (although, I've to admit, it tends to get blank stares from programmers that have never worked on embedded systems :-).



