Composer: IBM's new tool to develop serverless applications
Learning how to do sequential computing, where one calculation is made after the other, is easy. Anyone who learns programmings gets that. Parallel programming, which empowers super-computing calculations to be made simultaneously, is much harder, but doable. Concurrent computing, where multiple calculations are made within overlapping time frames, now that's hard. It's also extremely useful whether it's tracking multiple trains on a single train-line or multiple comments on a single Facebook page. That's why Facebook has worked hard on concurrent programming. Now, Facebook is sharing its newest debugger tool: RacerD, its new open source race detector.
As Facebook explains, the basic reason concurrency is difficult is that when we have two streams of instructions there is a fantastic number of potential schedules of execution. These are too many for a human or even a computer to explore. To get an idea of the scale of the challenge, say a program wanted to examine each of the different ways that two threads of 40 lines of code can interact concurrently, or "interleavings" in concurrency jargon. Even checking these by brute-force at a blazing rate of one billion interactions per second, it would would take millions of years.
Indeed, Facebook concluded it was impossible to check all the possibilities by brute force. With RacerD, however, Facebook claims it can analyze the possible results in less than 15 minutes and for much larger programs than 80 lines.
RacerD does this by searching for data races -- synchronized memory accesses, where one is a write -- in Java programs. To save time, it does this without running the program it is analyzing. To do this, RacerD employs symbolic reasoning to quickly cover an app's many possible paths.
Specifically, RacerD uses the theory of Concurrent Separation Logic. This logic enables the debugger to avoid enumerating interleavings, and scales concurrent checking to a reasonable rate of time.
RacerD is still far from perfect. It's just far more practical than anything else to date.
This program shows that a static concurrency analysis can be effectively applied at Facebook development speed and scale requirements. In other words, it's fast enough to deal with Facebook's enormous frequently modified codebase.
To manage this, it uses a high degree of automation to track the relationships between threads, locks, and memory without requiring a programmer to specify which bugs to track down. This means that it can immediately scale to many programmers with low friction. Without speed, scale, and low friction, the News Feed application, where more than a 1,000 issues were addressed before concurrent code was deployed, wouldn't have been possible.
RacerD is still a work in progress. Still, anyone who works with concurrent programming in any language should take a long hard look at it.
As Facebook states, "Reasoning about concurrency has been studied for over 40 years and has seen many research advances."However, not much of the work has made it through to deployment where it can help programmers in their daily jobs. Now, it has.