Haskell's Missing Concurrency Basics (2016)(snoyman.com) |
Haskell's Missing Concurrency Basics (2016)(snoyman.com) |
Therefore, when two processes (let's name them A and B) want to output something at the same time, the result is going to be AAAABBBB or BBBBAAAA (depending on the order in which the messages arrive in the mailbox), but never BBAABBAA or anything similar.
IMHO this is perfectly acceptable behaviour for a `map` function, since that name has gained the connotation that its purpose is to transform one 'collection' (Functor; whatever) into another, by pointwise, independent applications of the given function. Providing a function/action which breaks this independence (by writing to the same handle) breaks this implicit meaning. Heck, I'd consider it a code smell to combine interfering actions like this using a non-concurrent `map` function; I would prefer to define a separate function to make this distinction explicit, e.g.
-- Like 'map', but function invocations may interfere with each other (you've been warned!)
runAtOnce = map
With that said, I recognise that there's a problem here; but the problem seems to be 'mapping a self-interfering function'. If we try to make it non-interfering, we see that it's due to the use of a shared global value (`stdout`); another code smell! Whilst stdout is append-only, it's still mutable, so I'd try to remove this shared mutable state. Message passing is one alternative, where we can have each call/action explicitly take in the handle, then pass it along (either directly, or via some sort of "trampoline", like an MVar). This way we get the "concurrent from the outside, single-threaded on the inside" behaviour of actor systems like Erlang. In particular, it's easy to make sure the handle only get passed along when we're 'finished' with it (i.e. we've written a complete "block" of output).
Surely if you can pass your IO handles to all functions that need them, you can decide on a mutexing/buffering strategy at the top of your program, wrap the standard IO interface with a delegate that does so, and pass it on. Then, for all libraries called thereafter to use it consistently isn't just a no-brainer, it's an outright given, isn't it? There's no global (impure, non-functional) handle to stdout, is there?
This distinction is often inconsequential, but this case seems to rely on how we combine those "actions" together (which, due to laziness, may happen far away from where/when the functions are called; see 'lazy IO'). For sequential IO we can combine things with Applicative and Monad, which gives us a definite order, but using these in a concurrent setting would cause too much synchronisation and determinism to be useful. I've not done enough concurrent Haskell to know how the various alternatives stack up; although I did play with Arrow many years ago, before it fell out of favour (seemingly for Profunctors?).
Even if you do as you say, you can still bypass it by writing to stdout directly outside of your stable buffering mechanism. But at that point the language isn't to be blamed here.
EDIT: this is an honest question, I was shocked to read what was in the article.
Haskell's built-in string type is a list of characters. This is mostly for historical reasons, but it's also handy in education (installing extra packages is a barrier for learners; list processing is common in introductory courses, but lists are polymorphic/generic in their element type; lists of characters are a nice concrete type, which follows on easily from "hello world"); also there are arguments about the theoretical elegance of linked lists, KISS for the builtins, whether there's concensus on what the best alternative is, etc.
Anyone who cares about Haskell performance will have hit this early on, and be using a different string implementation, as mentioned in the article. In particular there's ByteString for C-like arrays of bytes, and there's Text which is just a ByteString with extra metadata like character encoding. In fact, ByteString doesn't have to be a single contiguous array: it can be a list of "chunks", where each chunk contains a pointer to an array, an offset and a length; this speeds up many operations, e.g. we can append ByteStrings by adding chunks to the list (pointing to existing arrays), we can take substrings by manipulating the offsets and lengths, etc. This is all perfectly safe and predictable since the data is immutable, where other languages which allow mutation might prefer to make copies of the data to reduce aliasing.
The other aspect is the buffering mode of the handle, which is discussed a little in the article and its comments (e.g. line-based buffering, etc.).
When I first read your example, it sounded like you were saying that the IO process would exhaust all messages from one source process before processing any messages from the other, no matter what order they arrived in.
Monadic I/O on its own doesn't make any guarantees, or impose any requirements, about locking external resources. If stdout is locked (from within the monad, or not), then that's the state the world arrives in for your effect. If not, then it's not. They are orthogonal concerns.
https://hackage.haskell.org/package/parallel-3.2.1.1/docs/Co...
Monad is effectively Haskell's definition of time: `A >> B` means A followed by B, `B >> A` means B followed by A. Yet Monad can't express concurrency; for that we need something else (e.g. Arrow).
> putStrLn either acquires a lock or it doesn't
It's not that simple: there's no point aquiring a lock after the text has been written; or relinquishing a lock before it's been aquired. To specify what we want, we need some way to sequence actions, and that's exactly what Monad is, i.e. we want `putStrLn` to be:
getLock >> writeTheString >> freeLock
getLock >> putChar 'f' >> putChar 'o' >> putChar 'o' >> putChar '\n' >> freeLock
As an alternative, we might imagine an "execute concurrently" combinator like `<&>` to complement `>>`, where `A <&> B` evaluates non-deterministically to either `A >> B` or `B >> A`. Yet this isn't particularly good, since `(A >> B) <&> (C >> D)` can only evaluate to either `A >> B >> C >> D` or `C >> D >> A >> B`; there's no possibility for traces like `A >> C >> B >> D`, so we lose a lot of the reason to use concurrency.
One way to fix this is to define another way of sequencing, e.g. `A ->> B`, which behaves like `A >> B`. We can then pick one of these, e.g. `->>`, to interact with `<&>`, such that:
(A ->> B) <&> (C ->> D)
A >> (B <&> (C ->> D))
C >> ((A ->> B) <&> D)
putChar 'f' ->> putChar 'o' ->> putChar 'o' ->> putChar '\n'
putChar 'f' >> putChar 'o' >> putChar 'o' >> putChar '\n'
Can we implement `<&>` with threads and `>>` with locks? Sure; but we can also think about these things in a "more Haskelly" way, with combinators, equational laws, etc.
Ok, sure, but that's how IO Haskell in Haskell actually works. There's arguably a principled reason for that. The IO monad is there to solve a problem that's particular to lazy languages: that it's difficult to reason about the order of evaluation and hence of side effects. That's conceptually completely different from the problems raised by concurrency, which are pretty much the same regardless of whether your programming language uses strict evaluation or lazy evaluation. Fundamentally, there is no sane way for >> to guarantee that no other thread within the process is competing for the same resource. >> can't know about every resource out there. Its instance for (IO a) can, however, make real guarantees about evaluation order, without knowing anything about what various IO actions are actually doing.
One can come up with all sorts of schemes for concurrency combinators (and Haskell has no monopoly on defining combinator libraries), but in the end, to avoid two threads writing to stdout at the same time, there is going to have to be some code somewhere that acquires a lock on a file handle. That code has to live in the relevant library functions, not in the implementations of the combinators.