DHO is Mostly Confused

Rants from Devon H. O'Dell

Monitors are hard to use. Per Wikipedia’s entry on the topic, “a monitor is a synchronization construct that allows threads to have both mutual exclusion and the ability to wait (block) for a certain condition to become true.” The use case for such a construct is often to signal other threads that new work may be completed. Unfortunately, they’re really easy to use incorrectly, largely because many APIs for them are terrible.

I’m finally writing Go. Although I was very active in contributing to the project for the first two-and-a-bit years, I’ve been pretty absent since 2012. Initially, I contributed because I am a fan of Plan 9 from Bell Labs and of FreeBSD. I loved the idea of having a usable, CSP-inspired language, but the initial release of Go only ran on Linux and OS X. I only had a FreeBSD system at the time, so I ported the compiler toolchain, runtime, and standard library to FreeBSD (with a good bit of education on debugging from Russ Cox).

Does rote learning have a place in computer science education? In my talk at QCon, I stated:
[Learning through discovery] is so much better than this typical, learn-by-rote method of teaching that we all sort of think of as teaching…
I just read a blog post by Zed Shaw suggesting that rote learning is basically required to become skillful in the field. I came into the article wholly skeptical – I haven’t always been a fan of what Zed writes, and my own research seemed to contradict what I thought the thesis would be.

I like coroutines. The other day on my team’s Slack channel, someone introduced Adam Dunkels’ protothreads. Either I hadn’t seen these before or had forgotten them, but it looked cool. A short conversation ensued, and at some point a colleague offered:
i can’t ever decide if i like [coroutines] or not. so ignoring that, i think there’s a decent heuristic: something like tatham’s coroutines will provoke a conversation every time you use it.

The C language is infamous for undefined behavior. Fantastic, multi-part articles by Chris Lattner and John Regehr have made their rounds over the years, describing several instances of undefined behavior. In particular, they describe how compilers are allowed to assume it does not occur in correct C programs, and therefore make optimizations that seem to remove correctness from programs. The intent of these posts seems to be to educate people that they should be aware of what consitutes undefined behavior.