5 ms·

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

deleted 12y ago
[deleted]
yshalabi 12y 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 12y 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.
  - rthomas6 12y ago
    >two parallel operations happened in the wrong order. I thought separate functions weren't allowed to have dependencies like this?
    - taeric 12y ago
      Simply put, not everything is commutative.
  - marcosdumay 12y ago
    You can't get deadlocks and data races on pure code. Once your code is in a monad, every one of those problems may be back (including memory race).
    - elihu 12y ago
      The IO monad in particular. Monads by themselves don't introduce races/deadlocks.
- codygman 12y ago
  In regards to pointers and pure functional languages: https://ghc.haskell.org/trac/ghc/wiki/StaticPointers https://ghc.haskell.org/trac/ghc/wiki/StaticPointers
cies 12y 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-examples-of-software-transactional.html http://computationalthoughts.blogspot.nl/2008/03/some-exampl...
elihu 12y 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

deleted 12y ago

[deleted]

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 12y 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.
- rthomas6 12y ago
  >two parallel operations happened in the wrong order. I thought separate functions weren't allowed to have dependencies like this?
  - taeric 12y ago
    Simply put, not everything is commutative.
- marcosdumay 12y ago
  You can't get deadlocks and data races on pure code. Once your code is in a monad, every one of those problems may be back (including memory race).
  - elihu 12y ago
    The IO monad in particular. Monads by themselves don't introduce races/deadlocks.
codygman 12y ago
In regards to pointers and pure functional languages: https://ghc.haskell.org/trac/ghc/wiki/StaticPointers https://ghc.haskell.org/trac/ghc/wiki/StaticPointers

cies 12y 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-examples-of-software-transactional.html http://computationalthoughts.blogspot.nl/2008/03/some-exampl...

elihu 12y 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