Comic for March 31, 2009: Good Work Indeed

The same could be said for cook­ies, cheese­cake, choco­late pies, and kittens.

Hey, that error mes­sage looks awfully familiar…

Oh, and are you curi­ous about that memo Pro­fes­sor Donly is hold­ing? You are? Then boy-​howdy, today is your lucky day!

(Read beneath the fold to see what I mean.)




CHRONOS has been giving us a heck of a time recently. We put stuff in and it keeps shoot­ing more stuff back out at us. Just yes­ter­day Sasha tried putting Snootchums through the machine; 90 sec­onds later, out popped 367 clones. Adorable? Sure. But unacceptable.

We’ve pin­pointed the prob­lem: an update made to the tar­get­ing system code last week, revi­sion 717. This was part of the major con­cur­rency update that Jen and Arnold (but mostly Jen) have been work­ing on for the past sev­eral months. The update was meant to speed up com­pu­ta­tion suf­fi­ciently so that we could dynam­i­cally cal­cu­late long tra­jec­to­ries – that is, so we could travel fur­ther than 100 sec­onds from the present with­out having to pre-​compute the whole damn trip on AEON. We greatly appre­ci­ate their tire­less efforts on this cru­cial aspect of the project; we’d appre­ci­ate it even more if the damn thing worked.

I’ve spent the last 13 hours star­ing at the code, and here is my deter­mi­na­tion:

[Editor’s note: Lots of jargon in the next para­graph. The non-technically-minded in the crowd may just want to skip it. Heck, I’m a CS major and most of it is Greek to me. I’m pretty sure he’s just saying that things are borked. -Greg]

Lock­ing is cur­rently imple­mented under the assump­tion of forward-​flowing time. Unfor­tu­nately, this assump­tion breaks down upon acti­va­tion of the machine. Cer­tain threads of com­pu­ta­tion are man­gled tem­po­rally. It becomes pos­si­ble for a thread to obtain a locked lock by observ­ing the state of the machine at an ear­lier point in time and retriev­ing the lock then.

Essen­tially, threads of code are get­ting into places they shouldn’t be. This means cer­tain loops are being exe­cuted end­lessly until there’s a buffer over­run some­where. Or some­thing like that. Dammit, Jen, I’m a physi­cist, not a com­puter scientist!

‘But Dr. Donly!’ I hear you ask. ‘The clones! How do the clones figure into this?’ Well, HOLD ONTO YOUR HORSES and I’ll TELL YOU. Sheesh.

So: the end result of all Jen’s crappy code is that our TTOs are being launched into what I’m dub­bing ‘Unfortunately Tight Loops’. Let’s take Snootchums as an exam­ple. We zap him with the machine. The code goes hay­wire. Snootchums gets sent three microsec­onds into the past. Now (or rather, then) there are two Snootchum­ses. Three microsec­onds pass. Since mul­ti­ple threads of com­pu­ta­tion all think they’re run­ning the show, the machine incor­rectly decides to zap both of these Snootchum­ses three microsec­onds into the past. Now (i.e., then) there are four Snootchumses.

You can imag­ine how this goes, until finally the machine can’t take any more and barfs all these Snootchum­ses out into the Con­tin­uum. God only knows where. For all we know there’s a six-million-year-old menagerie of Snootchum­ses out there drift­ing silently through the Crab Nebula.

Why haven’t we seen this prob­lem before? Hell if I know. Is it because the new algo­rithm is of a much greater com­plex­ity than the old one? Maybe. Or MAYBE it’s because – unlike the present update – the ORIG­I­NAL code was writ­ten by some­one MAR­GIN­ALLY MORE COM­PE­TENT than a HALF-​DRUNKEN BABOON. You know what? That sounds about right to me. Yeah, let’s go with that.

Anyway, the code has been reverted. It’s going to stay that way until you people figure out a solu­tion. You might want to think long and hard about this memo before you go on fid­dling with the tar­get­ing system, okay?

O. R. Donly