Better multithreading offered by Columbia U researchers 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 …
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?
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 isn't the point to make the code race free. It isn't supposed to guarantee that what you get out the other side is the right answer, just that what you get out the other side is always the same answer for the same input. It may be the case that a data race causes the answer to be wrong, but in that case subsequent runs will get you the same wrong answer consistently.
Of course, as I've said in another comment, this basically has no application to real world programs and is essentially theoretical bullshit, but the theory is sound.
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.
They basically admit it in the paper, this simply doesn't work in the real world. Essentially any program which uses a call like select() to non-deterministically wait on input from outside the process entirely blows up their attempt to make thread runs deterministic. While is... er... every useful program in the entire world. Their hack around to reduce these programs to the simple threading model they can work with essentially destroys the advantage to threading in the first place.
Hell, the whole system requires that programmers can correctly identify critical sections in their code and flag them with synchronisation primitives like pthread_mutex_lock()/_unlock() pairs. If you're relying on them to know that much, then surely you can rely on them to understand what a race condition is, and what happens when you change the execution order of two or more critical sections.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
