|
Shared Responsibility
Dynamic Analysis for Race Conditions and Deadlocks in Java (Bryon Moyer)
Let’s face it: multi-threading has created some pains in the… well, as Forrest would say, butt-tox. You used to be able to write code assuming you had your own nice little sandbox, especially in a more protective language like Java, which allows you to be reasonably sure that some other schmo’s pointer won’t come weaseling its way onto your turf. But now you can have multiple threads that may want to get to the same pieces of data, so the threads have to learn how to play nice together, and that’s not always easy.
The issues all build on a few key concepts that at first blush seem so simple and straightforward. Then again, if they were, we wouldn’t be having this little chat, now, would we? So we’ll start at the start, or at least close. What’s the problem with multiple threads sharing data? Well, there’s the obvious first problem of only one entity having access to the data at a time, from a physical standpoint. An arbiter can generally handle this, granting memory access in turn to requesters. Yes, theoretically there’s some extremely tiny chance that two requests could happen at exactly the same attosecond causing some metastability-like confusion for an arbiter (even if you build in some kind of tie-breaking bias, you can always come up with some similar unlikely scenario), but – and this is key – that can generally be recovered from pretty easily. That’s not the big problem. [more]
|
