Archive
Shameless
If you glance over to the right and scan down, you’ll see that two of the widgets I chose to display on this god-forsaken blog are titled “Top Clicks” and “Community“. Recently, I noticed that the link to Diana Dylan’s community gravatar icon has been consistently appearing in the “Top Clicks” list. Gee, I wonder why? Shame on you clickers! 🙂
Periodic Processing With Standard C++11 Facilities
With the addition of the <chrono> and <thread> libraries to the C++11 standard library, programs that require precise, time-synchronized functionality can now be written without having to include any external, non-standard libraries (ACE, Boost, Poco, pthread, etc) into the development environment. However, learning and using the new APIs correctly can be a non-trivial undertaking. But, there’s a reason for having these rich and powerful APIs:
The time facilities are intended to efficiently support uses deep in the system; they do not provide convenience facilities to help you maintain your social calendar. In fact, the time facilities originated with the stringent needs of high-energy physics. Furthermore, language facilities for dealing with short time spans (e.g., nanoseconds) must not themselves take significant time. Consequently, the <chrono> facilities are not simple, but many uses of those facilities can be very simple. – Bjarne Stroustrup (The C++ Programming Language, Fourth Edition).
Many soft and hard real-time applications require chunks of work to be done at precise, periodic intervals during run-time. The figure below models such a program. At the start of each fixed time interval T, “doStuff()” is invoked to perform an application-specific unit of work. Upon completion of the work, the program (or task/thread) “sleeps” under the care of the OS until the next interval start time occurs. If the chunk of work doesn’t complete before the next interval starts, or accurate, interval-to-interval periodicity is not maintained during operation, then the program is deemed to have “failed“. Whether the failure is catastrophic or merely a recoverable blip is application-specific.
Although the C++11 time facilities support time and duration manipulations down to the nanosecond level of precision, the actual accuracy of code that employs the API is a function of the precision and accuracy of the underlying hardware and OS platform. The C++11 API simply serves as a standard, portable bridge between the coder and the platform.
The figure below shows the effect of platform inaccuracy on programs that need to maintain a fixed, periodic timeline. Instead of “waking up” at perfectly constant intervals of T, some jitter is introduced by the platform. If the jitter is not compensated for, the program will cumulatively drift further and further away from “real-time” as it runs. Even if jitter compensation is applied on an interval by interval basis to prevent drift-creep, there will always be some time inaccuracy present in the application due to the hardware and OS limitations. Again, the specific application dictates whether the timing inaccuracy is catastrophic or merely a nuisance to be ignored.
The simple UML activity diagram below shows the cruxt of what must be done to measure the “wake-up error” on a given platform.
On each pass through the loop:
- The OS wakes us up (via <thread>)
- We retrieve the current time (via <chrono>)
- We compute the error between the current time and the desired time (via <chrono>)
- We compute the next desired wake-up time (via <chrono>)
- We tell the OS to put us to sleep until the desired wake-up time occurs (via <thread>)
For your viewing and critiquing pleasure, the source code for a simple, portable C++11 program that measures average “wakeup error” is shown here:
The figure below shows the results from a typical program run on a Win7 (VC++13) and Linux (GCC 4.7.2) platform. Note that the clock precision on the two platforms are different. Also note that in the worst case, the 100 millisecond period I randomly chose for the run is maintained to within an average of .1 percent over the 30 second test run. Of course, your mileage may vary depending on your platform specifics and what other services/daemons are running on that platform.
The purpose of writing and running this test program was not to come up with some definitive, quantitative results. It was simply to learn and play around with the <chrono> and <thread> APIs; and to discover how qualitatively well the software and hardware stacks can accommodate software components that require doing chunks of work on fixed, periodic, time boundaries.
In case anyone wants to take the source code and run with it, I’ve attached it to the site as a pdf: periodicTask.pdf. You could simulate chunks of work being done within each interval by placing a std::this_thread::sleep_for() within the std::this_thread::sleep_until() loop. You could elevate numLoops and intervalPeriodMillis from compile time constants to command line arguments. You can use std::minmax_element() on the wakeup error samples.
Happy Holidays!!!!!
Let’s Go Snarkling!
While scrolling through my @bulldozer0 twitter timeline, I often transition into “snark” mode. While snarkling around in the twitpool, I like to lob little, annoying, stink bombs into the foxholes of other tweeters like me. You know, those people who think their tweets channel profound pearls of wisdom into the world as if they originated from the lips of god herself:
If you’re a tweeter, consider putting on a pair of flippers, diving in, and giving snarkling a go.
“A conscience is what feels bad when everything else feels so good.” – Steven Wright
Someone Broke My Radar!
D’oh! Someone broke my freakin’ radar! When I went to bed last night and glanced out my window, it was happily spinning away in my backyard diligently searching for airborne intruders. When I woke up, it was all in pieces.
After dragging the heap of parts into my garage, I snapped this pic of the atrocity:
Damn, I gotta find the culprit who did this. If you have any information regarding this grave injustice, either call 1-800-BD00 or post your evidence in the comments section. There’s a brand new bulldozer00.com T-shirt waiting in the wings for the person who provides the information that leads to the capture and conviction of the perpetrator(s).
At The Top Of The List
Because of the widespread wreckage caused by the 2008 financial meltdown and the fact that not one single gov-handout-taking banker fat cat is behind bars, I harbor a deep disdain for financial institutions. Since the impeccably infallible Goldman Sux is high on my turd list, I quickly snatched up Steven Mandis’s “What Happened to Goldman Sachs: An Insider’s Story of Organizational Drift and Its Unintended Consequences” to harden my mental model of the company. One of my favorite passages in the book is:
Before this increased emphasis on quantification and accountability, people were willing to make more time for each other and help think through issues. Bankers didn’t worry about filling out time sheets or taking credit. They worried instead more about giving clients better advice. – Steven Mandis
So, if your org’s so-called leadership starts cranking up the volume on “metrics!“, “accountability!“, and/or “performance management!” in textbook MBA fashion, then beware of what the future holds. It simply broadcasts their knee-jerk cluelessness and utter lack of ideas on how to really improve your borg.
Energized, But Goal-less
If you’ve read more than a couple of posts on this gawd-forsaken blawg, then you might have correctly arrived at the conclusion that Dilbert cartoonist Scott Adams is one of my all time favorite people. In his latest, laughingly good read, “How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life“, Scott shares his sole reason for blogging:
The main reason I blog is because it energizes me. I could rationalize my blogging by telling you it increases traffic on Dilbert.com by 10 percent or that it keeps my mind sharp or that I think the world is a better place when there are more ideas in it. But the main truth is that blogging charges me up. It gets me going. I don’t need another reason.
Ding! That’s Ed Zachary why I blog too. I blog for the energy boost. I’m not actively hoping to achieve anything specific when I blog. I just do it… to do it. Every time I click the “Add New Post” button on my WordPress dashboard and I’m presented with an inviting, blank, white canvas, I have no freakin’ idea what goo will get splotched onto it and subsequently launched into the ether.
But wait! Scotty also pens this:
Throughout my career I’ve had my antennae up, looking for examples of people who use systems as opposed to goals. In most cases, as far as I can tell, the people who use systems do better. The systems-driven people have found a way to look at the familiar in new and more useful ways. To put it bluntly, goals are for losers. That’s literally true most of the time. For example, if your goal is to lose ten pounds, you will spend every moment until you reach the goal—if you reach it at all—feeling as if you were short of your goal. In other words, goal-oriented people exist in a state of nearly continuous failure that they hope will be temporary.
W00t! I’m not a “goal-oriented” person either. I never have been and, up until now, I’ve often felt weird as “A Man Without A Country, uh, I mean, Goal“. After all, it’s difficult not to feel weird when you’re surrounded 8 hours a day by lots of goal-oriented people, most of whom auto-expect everybody else to be goal-driven too.
Scott Adams is a rare bird. To me, he’s a dirty rich dude who deserves to be dirty rich. Unlike many dirty rich people, he’s a a creator with a sense of humility. A real gem.
Manage-ification By Growth
Somewhere on the road from small startup sensation to huge institutional borgdom, the oft-repeated process of “manage-ification by growth” fires up and kicks into high gear. It’s inevitable, or is it?
C++1y Automatic Type Deduction
The addition, err, redefinition of the auto keyword in C++11 was a great move to reduce code verbosity during the definition of local variables:
In addition to this convenient usage, employing auto in conjunction with the new (and initially weird) function-trailing-return-type syntax is useful for defining function templates that manipulate multiple parameterized types (see the third entry in the list of function definitions below).
In the upcoming C++14 standard, auto will also become useful for defining normal, run-of-the-mill, non-template functions. As the fourth entry below illustrates, we’ll be able to use auto in function definitions without having to use the funky function-trailing-return-type syntax (see the useless, but valid, second entry in the list).
For a more in depth treatment of C++11’s automatic type deduction capability, check out Herb Sutter’s masterful post on the new AAA (Almost Always Auto) idiom.
Big Design, But Not All Upfront
When not ranting and raving on this blawg about “great injustices” (LOL) that I perceive are keeping the world from becoming a better place, I design, write, and test real-time radar system software for a living. I use the UML before, during, and after coding to capture, expose, and reason about my software designs. The UML artifacts I concoct serve as a high level coding road map for me; and a communication tool for subject matter experts (in my case, radar system engineers) who don’t know how to (or care to) read C++ code but are keenly interested in how I map their domain-specific requirements/designs into an implementable software design.
I’m not a UML language lawyer and I never intend to be one. Luckily, I’m not forced to use a formal UML-centric tool to generate/evolve my “bent” UML designs (see what I mean by “bent” UML here: Bend It Like Fowler). I simply use MSFT Visio to freely splat symbols and connections on an e-canvas in any way I see fit. Thus, I’m unencumbered by a nanny tool telling me I’m syntactically/semantically “wrong!” and rudely interrupting my thought flow every five minutes.
The 2nd graphic below illustrates an example of one of my typical class diagrams. It models a small, logically cohesive cluster of cooperating classes that represent the “transmit timeline” functionality embedded within a larger “scheduler” component. The scheduler component itself is embedded within yet another, larger scale component composed of a complex amalgam of cooperating hardware and software components; the radar itself.
When fully developed and tested, the radar will be fielded within a hostile environment where it will (hopefully) perform its noble mission of detecting and tracking aircraft in the midst of random noise, unwanted clutter reflections, cleverly uncooperative “enemy” pilots, and atmospheric attenuation/distortion. But I digress, so let me get back to the original intent of this post, which I think has something to do with how and why I use the UML.
The radar transmit timeline is where other necessarily closely coupled scheduler sub-components add/insert commands that tell the radar hardware what to do and when to do it; sometime in the future relative to “now“. As the radar rotates and fires its sophisticated, radio frequency pulse trains out into the ether looking for targets, the scheduler is always “thinking” a few steps ahead of where the antenna beam is currently pointing. The scheduler relentlessly fills the TxTimeline in real time with beam-specific commands. It issues those commands to the hardware early enough for the hardware to be able to queue, setup, and execute the minute transmit details when the antenna arrives at the desired command point. Geeze! I’m digressing yet again off the UML path, so lemme try once more to get back to what I originally wanted to ramble about.
Being an unapologetic UML bender, and not a fan of analysis-paralysis, I never attempt to meticulously show every class attribute, operation, or association on a design diagram. I weave in non-UML symbology as I see fit and I show only those elements I deem important for creating a shared understanding between myself and other interested parties. After all, some low level attributes/operations/classes/associations will “go away” as my learning unfolds and others will “emerge” during coding anyway, so why waste the time?
Notice the “revision number” in the lower right hand corner of the above class diagram. It hints that I continuously keep the diagram in sync with the code as I write it. In fact, I keep the applicable diagram(s) open right next to my code editor as I hack away. As a PAYGO practitioner, I bounce back and forth between code & UML artifacts whenever I want to.
The UML sequence diagram below depicts a visualization of the participatory role of the TxTimeline object in a larger system context comprised of other peer objects within the scheduler. For fear of unethically disclosing intellectual property, I’m not gonna walk through a textual explanation of the operational behavior of the scheduler component as “a whole“. The purpose of presenting the sequence diagram is simply to show you a real case example that “one diagram is not enough” for me to capture the design of any software component containing a substantial amount of “essential complexity“. As a matter of fact, at this current moment in time, I have generated a set of 7+ leveled and balanced class/sequence/activity diagrams to steer my coding effort. I always start coding/testing with class skeletons and I iteratively add muscles/tendons/ligaments/organs to the Frankensteinian beast over time.
In this post, I opened up my trench coat and showed you my… attempted to share with you an intimate glimpse into the way I personally design & develop software. In my process, the design is not done “all upfront“, but a purely subjective mix of mostly high and low level details is indeed created upfront. I think of it as “Big Design, But Not All Upfront“.
Despite what some code-centric, design-agnostic, software development processes advocate, in my mind, it’s not just about the code. The code is simply the lowest level, most concrete, model of the solution. The practices of design generation/capture and code slinging/testing in my world are intimately and inextricably coupled. I’m not smart enough to go directly to code from a user story, a one-liner work backlog entry, a whiteboard doodle, or a set of casual, undocumented, face-to-face conversations. In my domain, real-time surveillance radar systems, expressing and capturing a fair amount of formal detail is (rightly) required up front. So, screw you to any and all NoUML, no-documentation, jihadists who happen to stumble upon this post. 🙂
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 