Fix your damned data races

https://blog.mozilla.org/nnethercote/2015/02/24/fix-your-damned-data-races/

by dbaupp • 11 years ago

130 28 11 years ago

blog.mozilla.org

falcolas3• 11 years ago

I'm reminded of an image I saw a few weeks ago:

The sign says "You must be at least this tall to write threaded code", and it's been placed 8 feet off the floor, next to a well respected senior developer who must constantly write threaded code (and who, when standing, is a good two feet shy of the sign).

Threading properly is hard, and yet it's becoming more and more integrated into our lives, from our browser to our backend interpreters like Node...

Concurrency needs a Rust-like language to protect us at compile time against data races. The restrictions it would impose on what we could do might be abhorrent to our generation of coders, but the benefits would be far reaching.

icebraining• 11 years ago

https://twitter.com/themitcho/status/308026012455821312

gsnedders• 11 years ago

That appears to be David Baron, of Mozilla.

_pmf_• 11 years ago

Shared memory is hard. Using threading in conjunction with message passing is comparatively nice and safe.

falcolas3• 11 years ago

Race conditions can and do occur with message passing as well. All that is required is to depend on operations split between threads (processes, machines) occurring in a particular order, and you will eventually run into a race condition when you try and run the code concurrently.

The problem occurs in that both programmers and our tools are terrible at guessing when such order dependencies will occur, except when working with "embarrassingly parallel" tasks.

barrkel• 11 years ago

Figuring out the possible global combinations of multiple different interacting state machines can still be tricky. You can still easily get into racy scenarios.

The problems you see with memory races (e.g. publishing a pointer to a structure which does not have all its construction memory stores retired) are at a different level of strangeness, however.

Profan• 11 years ago

While explicitly sharing memory isn't a great solution to threading, one shouldn't think message passing is some sort of panacea either, you can end up with things such as race conditions or deadlocks if you're not careful there as well.

Though it is admittedly a fair bit more sane for most applications.

steveklabnik2• 11 years ago

I wish I remember who I first heard say "everyone agrees shared mutable state is evil. Most languages deal with this problem by controlling the 'mutable.' Rust deals with this by controlling the 'shared.'

Message passing is another way of dealing with the 'shared,' too. But especially with the new RFC that just landed, Rust has some pretty amazing capabilities in this space that should make it incredibly useful for concurrency. And because it's based in the type system, not the language itself, you can take advantage of that safety and write your own concurrency abstraction with the same guarantees, esentially for free.

wizeman• 11 years ago

Luckily, it seems that Rust code is starting to get integrated into Firefox: https://twitter.com/indygreg/status/570010688027959297

steveklabnik2• 11 years ago

The goal is 'by the end of the year,' we're a very long way away from 'started' even.

pcwalton• 11 years ago

Concurrency needs a Rust-like language to protect us at compile time against data races. The restrictions it would impose on what we could do might be abhorrent to our generation of coders, but the benefits would be far reaching.

Not sure if this is what you meant, but Rust does protect against data races. You are unable to share data unless you use message passing, share read-only data, use atomics, or use mutexes.

rthomas62• 11 years ago

Does coding in a pure functional language like Haskell solve this problem?

yshalabi• 11 years ago

Yes. Functional languages are amenable to composition. Because of their "purity". This allows trivial extraction of parallelism/concurrency. No need to reason about interleaving and shared data and such.

But, I don't know if "use FP if you want parallelism" is an acceptable solution currently. My intuition is that latency sensitive application can't use these languages because they don't expose the low-level primitives (read pointers) that make the difference in such applications. But I haven't written and profiled enough FP code to know if this is absolutely the case.

zaphar• 11 years ago

No, Functional languages reduce the problems surface area but they don't eliminate it. You can still get data races and deadlocks in Haskell. They aren't the same as a memory race in say C where the contents of a variable might change out from under you in truly bizarre ways but you still get algorithmic races where the wrong answer comes our the other end because two parallel operations happened in the wrong order.

codygman2• 11 years ago

In regards to pointers and pure functional languages:

https://ghc.haskell.org/trac/ghc/wiki/StaticPointers

cies• 11 years ago

It does so mostly. And Haskell also provides clever tools to corner the remaining issues. Like state transactional memory (STM).

STM is actually really simple in Haskell, and implemented mostly as a library(!). Have a look:

http://computationalthoughts.blogspot.nl/2008/03/some-exampl...

elihu2• 11 years ago

It's possible to write race-prone code in Haskell if you have several threads reading and writing IORefs concurrently in the IO monad. There are plenty of safer alternatives, though, so there's not much point in writing software that way unless you're actually trying to create a race.

MVars can deadlock, but you can't accidentally mutate/read a value without taking the lock (unless you use IORefs in conjunction with MVars).

STM handles races by detecting them and re-starting a transaction if a race occurs, so races aren't possible. (Accessing IORefs is disallowed by the type system inside an STM transaction, so you're safe there.) STM also isn't susceptible to deadlocks, so it's generally the safest option if you need non-deterministic threading, and invoking transactions from the IO monad fits with the structure of your program.

There's also par/seq, strategies, and the Par monad which are great for parallel computation and aren't prone to races or deadlocks. They can be called from anywhere in a Haskell program and are deterministic -- they're guaranteed to always return the same result when given the same inputs. Results cannot depend on the order in which threads are scheduled.

tl;dr: don't use IORefs and you should be fine

josinalvo• 11 years ago

So, how could I fix the first example of the paper ? (https://www.usenix.org/legacy/events/hotpar11/tech/final_fil..., section 2.1)

codygman2• 11 years ago

I'm not much of a C programmer and don't know the answer, but a total guess based on intuition results in:

http://www.gnu.org/software/libc/manual/html_node/Atomic-Dat...

Fix your damned data races

Related Stories