CppCon Lightning Talk

Hey, the video of my lightning talk from CppCon is now available:

Please keep in mind that this was given at 8am on the third day of the conference, so I might sound a bit groggy. Also, I only had 15 minutes, and the talk was optimized to fill those 15 minutes, so at times I might have been talking a bit fast. So don’t judge my performance too harshly. Unfortunately there’s no video of the open content session where I gave the talk a second time with 45 minutes available (not that anyone probably wants to hear me speak for 45 minutes, but I think it did turn out better and I was able to take questions from the audience).

Advertisements

5 comments

  1. Well, I was there and I thought you did a good job; it was interesting enough to bring me to your blog, at the very least 🙂

    1. Yeah, I tend to be pessimistic about stuff like this. The talk probably went over better than I’m assuming it did. Thanks for the vote of confidence.

  2. I’m curious about your thoughts on the potential for TM going mainstream. I’ll admit that I think TM is intellectually super appealing, but I’m skeptical about how widely applicable it is. A few particular questions about your system (if there are explanations elsewhere I’d be happy with links):

    – Do I understand correctly that your TM system has an abstraction for “transactional memory cells” that application code has to wrap all it pieces of transactional state in?
    – You mention the issue with effects in the context of some UI action that might happen multiple times. Isn’t there a subtler problem with non-TM reads and writes in transactions? In regular old imperative programs there tends to be so many little bits of state hiding here and there. These cannot be rolled back in your system, right?
    – Without effect tracking in the type system (e.g. Haskell, Scala) it seems like the holes in library-based TM (see previous point) make it too fiddly to make it a default part of a language ecosystem. Do you think that’s right?

  3. I had been meaning to write about our use of transactional memory in more detail here on the blog, but now I’m doing that in a paper for the C++ standard committee working group on transactional memory. When that paper is done (slow going since I don’t have a lot of spare time to devote to it) I’ll post it here. In the meantime here’s some quick answers:

    – Yep, in our system the only stuff that gets transacted is stuff the lives in a “STM::Var” objects. The whole system is designed along the lines of Haskell’s STM system. We also, as a policy, require anything stored in a STM::Var to be either immutable or have any internal state also stored in STM::Var objects.
    – Any other side-effects are not rolled-back, so avoiding anything that isn’t idempotent is extremely important. In our system we have a way to blacklist functions so that they can’t be called from within a transaction, but it’s a run-time check. I’ve been toying with the idea of attempting to use Clang to write a static verifier for this, but just haven’t had time and in practice this is rarely an issue reducing the priority (in a team bigger than three people it might be more of an issue). As I stated in the talk, when we do run into side-effect problems it’s usually obvious where the problem is (e.g. a dialog box pops up a random number of times), and those are easily solvable by scheduling the side-effect to happen when the transaction commits. There have been a couple of instances where the side-effect issue was subtle, but debugging the issue wasn’t any worse than debugging a race-condition.
    – A library-only solution in C++ is a bit fiddly, I’ll concede that. I don’t know if we just have really good programming discipline (doubtful), have just been lucky (possible), or it just isn’t as fiddly as one would assume (leaning towards this, but don’t have enough data). And really we’re just aiming to beat programming with locks, which is setting the bar pretty low. I think the implicit system being proposed for inclusion in the C++ standard removes a lot of this fiddly-ness since everything you do in a transaction is transacted, not just the stuff that is declared in a “transactional variable”, and they have a statically verifiable white-listing system for which functions can be called in a transaction.
    – It would be really nice to have Haskell’s type-system in all this, but I failed to convince that powers that be that we should reimplement the application in Haskell.

  4. […] you happened to watch my lightning talk from CppCon then you heard me talk about how there was a case where one could still get deadlock when using […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: