SaaS data loss: The problem you didn’t know you had

Fail and You I don’t know about you, but every time I have to program with threads and shared resources, I want to remove my face incrementally with a salad fork. Locks, mutexes, the synchronized keyword; all of these things can strike fear into the heart of a green developer. Most seasoned developers just fall into a rut of depression when it’s time for multi-threading. Developers like me simply talk our way out of it. It’s easier than thinking.

That might all change soon.

Homework Is Hard. Let’s Play Video Games

Now I don’t know how you did it, but when I was in computer science class and the topic of threads and mutexes came up, I gave it a whole hearted fuck this and took a 45-minute bathroom break. In the typical American fashion, I expected somebody to bail my ass out when I had to do this in industry. And, if Sun’s transactional memory works, then all the suckers who stayed in class learned resource locking for nothing. Who’s smart now?

What I would have learned had I been more dedicated to my education were the two fundamental facts about multi-threading with locks:

1. You’re going to fuck it up.
2. If you think that you haven’t fucked it up, you have. You just don’t know it yet.

With that in mind, there are three ways to control concurrency with locks. First, you can make fine-grained locks, which require a lot of bookkeeping and management. Secondly, you can also make coarse-grained locks, which are easier to implement but lead to a lot of contention. Finally, and this is perhaps the easiest solution, you can kill yourself. Believe me, number three looks pretty tempting after trying to find a thread related Heisenbug for two weeks.

But, if transactional memory comes into the picture, concurrent programming doesn’t have such a pessimistic outlook. No longer do you have to worry about how to control atomicity, you only have to worry about where to control atomicity.

Transactional memory lets you do things like this:

atomic {
    MyObject obj = myHashMap.get(key);
    obj.setSomeValue(x);
    myHashMap.remove(obj);
    myList.add(obj);
}

These operations are performed atomically, and you don’t need to worry about how it happens. Man, that beats the shit out of studying. Who’s up for a beer?

We Set Up Camp at the Bottom of the Bell Curve

Transactional memory is nothing new. Like most suspiciously ideal things, it originated in academia, where professors would explain their ideas starting with spitefully impractical phrases like “imagine a machine with infinite memory…,” and students like me would put on our best display of counterfeit interest.

There are two approaches to transactional memory: software and hardware. In Software Transactional Memory (STM), the system needs a thread to keep track of memory access, which, as you can imagine, usually eats up more resources than it saves. Hardware Transactional Memory (HTM) handles these memory operations on a chip. While hardware seems like the way to go, it just brings up a whole new host of problems. HTM implementations usually require the programmer to know some really esoteric stuff about his code (like the number of cache lines accessed by his transactions – what the shit?), and you end up at the same place you started: salad fork to the face.

I don’t want to think. I want to get paid the most amount of money for the least amount of work. Somebody please do the hard stuff for me.

Sun has come up with an approach that appeals to the lowest common denominator. They call it Hybrid Transactional Memory (HyTM), and it’s essentially an STM implementation that will use HTM when it’s available. As HTM gets better, code that uses HyTM gets faster automatically: no changes needed. The Rock CPU features HTM, so this isn’t just academic chest thumping.

End result to you and me is win, and copious amounts of it. It lets us program like I did in the snippet above without giving a thought to how things get done. Plus, it’s a hearty fuck-you to that guy on your team who is eerily good at using threads and locks. That reign of passive aggressive nerd dominance is over. He’ll have to find something else to be better-than-everyone at, and Kendo doesn’t count, Poindexter.

Some Transactions Leave You With Genital Warts

Sun Microsystems is about to horsefuck the database world, and nobody sees it coming. Imagine a SQL database that can support the absurd level of concurrency promised by HyTM. Conveniently, Sun owns one of the most popular relational databases in the world: MySQL. If MySQL on a single Rock based system can outperform Oracle or Microsoft spread across many systems, then DBAs worldwide would gladly tell Larry Ellison or Steve Ballmer where to shove it.

But will it actually work? Sun published a few papers about HyTM last year, and they were a shot across the bow to Oracle. Sun, it seems, employs some of the same passive aggressive nerds that your organization does. In their papers, they showed the effect that HyTM has on BerkeleyDB. Rewritten using Sun’s scheme, BDB’s locking subsystem achieves several orders of magnitude more throughput as the number of threads grows linearly. Oracle owns Sleepycat Software, the developers of BerkeleyDB. The dicks have been thrown down, and Sun’s is dragging in the dirt.

Of course, this isn’t all a fellatio session. Sun has yet to pull it off. At one point, the Rock chip was due in 2008, but now it’s been delayed to 2009. They could still scrap it and leave us with a severe case of blue balls. HyTM could fail to live up to expectations, leaving me looking like an idiot, or worse, it would invalidate my American dream, that I can slack off with reckless disregard for myself and others and still count on somebody to save my ass. ®

Ted Dziuba is a co-founder at Milo.com You can read his regular Reg column, Fail and You, every other Monday.

Steps to Take Before Choosing a Business Continuity Partner