Better multithreading offered by Columbia U researchers
Reducing the bugs, improving the execution
Ensure Ease of Recovery with Asigra’s Agentless Software
Since world+dog uses multithreaded software, it’s nice to know that someone cares about what goes wrong with it.
A computer science group from Columbia University says it has a solution to “data races” in multithreaded programs, a common source of bugs and crashes. Its offering, called Peregrine, is the result of work at the Columbia Engineering School led by an assistant professor of computer science called Junfeng Yang.
In a paper called Efficient deterministic multithreading through schedule relaxation, co-authored with Heming Cui, Jingyue Wu, John Gallagher and Huayang Guo, Yang argues that most of a program's execution is race-free: “races tend to occur only in minor portions of an execution”, the paper states.
“Our main in developing Peregrine is that we can make threads deterministic in an efficient and stable way,” Yang says. “This prevents the random collisions that can occur in a non-deterministic system.”
The idea looks simple enough: the first time a program runs, Peregrine records a trace of the execution, computing an efficient plan for a group of threads. It can then “reuse the plan on subsequent groups [of threads] to avoid the cost of computing a new plan for each group,” Yang said.
Reusability of its execution plans, Yang says, is important to the long-term stability of the multithreading system. If the supervisor has to create new plans for any group of threads, it becomes more likely that some of its plans will have errors and create more collisions.
Avoiding crashes has a side-benefit, since crashes often leave machines vulnerable to attackers.
The research was published at the 23rd ACM Symposium on Operating Systems Principles, and the full paper can be found here. ®
COMMENTS
Yeah, but what happens when the circumstances change?
More records, different type of data, different load on the rest of the machine, changes in network environment, etc, etc. I just can't help being sceptical about their claim. And how big are their binaries? What's the performance like? How much longer does it take them to write (and tune) their program? Is it going to be a free and open source compiler?
And this is useful for what?
Been programming heavily multi-threaded apps for years and the fact is, if you understand threading well enough to be considered a useful contributor to the development of a threaded application, then this is a non-issue anyway.
Schedules for threads have to be determined by the data set of the application. Otherwise, you're probably not threading for any particular reason and therefore attempting to precalculate and optimal threading path is a waste of time and effort.
I am however considering purchasing a book on multithreading patterns to see if there is anything to offer in this direction. But in reality, race conditions are a flaw typically faced by bad planning.
So how do you know the first run was race free?
Race conditions are sporadic and often you don't even know they're happening except by analysing some vague runtime error for hours. Even if you write code with concurrency in mind you might still screw up in some way which is non too obvious and requires lots of excruciating debugging.
So you run this application the first time. Even if the developers are standing over it, it may *seem* to work but you have no way of knowing for sure. And if the environment changes in some way, e.g. CPU load, hardware upgrade, network congestion or whatnot then even if the plan were originally functioning it may no longer do so under changed conditions. Also, developers aren't likely to be standing over at deployment so who is observing to see that the thing seems to work?
Perhaps the paper accounts for some of these things, but I reckon multithreading will be as hard as its always been. The best way to avoid race conditions is to isolate the concurrent part as much as possible. Make the API a blackbox so that caller doesn't care how stuff gets done, just that it is. And then inside the blackbox make best use the facilities the language provides. e.g. Java implements various useful concurrency patterns such as thread pools and executors. And make sure it's written by someone who knows what they're doing rather than just slathering synchronized keywords all over the entry points.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
