
A Dismal Guide to Concurrency - logicalstack
http://www.facebook.com/note.php?note_id=379717628919
======
kaib
Nice article.

While I have high respect for the exposition in this article, and by extension
Mr. Vogels work that the author makes a reference to, I think it's a tad too
early declare eventual consistency a clear winner. In fact, I think it's too
early to declare that a there is a contest in the first place. While there
seems to be some level of agreement that partition tolerance is required for
real world systems consistency vs. availability is more of a continuum instead
of two discrete choices. I find that in day to day work some data requires a
paxos level of consistency (say a configuration file containing your inter-
cluster topology) and some data can be highly inconsistent (like activity data
such as 'read' status of emails).

As a side-note, I would argue that all eventual consistent systems rely on
some domain knowledge about the data that makes it possible for the system to
reliably merge conflicting data. Such algorithms usually have the property
that they only move state in one direction, emails only move from unread to
read for example.

What I'm trying hard to figure out is how Consistent, Available and Partition
Tolerance map onto Intelligence, Emotional Stability and Good Looks. Do we
always require Good Looks and thus end up choosing between Intelligence and
Emotional Stability or ...

~~~
aristus
I happen to agree, funnily enough. I only talked about the extreme ends of the
spectrum. I suspect that C/A systems have a natural place, say, up to
datacenter-sized systems. After that they founder on latency and partitions.

The big thing about Dynamo in particular isn't eventual consistency but
_configurable_ consistency. You can specify how much consistency you want and
how long you will wait for it.

------
sjs
Great footnote. I'm undecided if I should tackle Clojure or Erlang next. Each
one is excellent and interesting in its own way.

> A lot of writeups repeat a "nine nines", ie 99.9999999% reliability claim
> for Erlang-based Ericsson telephone switches owned by British Telecoms. This
> works out to 31 milliseconds of downtime per year, which hovers near the
> edge of measurability, not to say plausibility. I was present at a talk
> Armstrong gave in early 2010 during which he was asked about this. There was
> a little foot shuffling as he qualified it: it was actually 6 or so seconds
> of downtime in one device during a code update. Since BT had X devices over
> Y years, they calculated it as 31ms of average downtime per device per year.
> Or something like that. Either way it's an impressive feat.

~~~
gtani
what's up with

\- erlang: R14 and somehting like Memory management threads

[http://groups.google.com/group/ceug/browse_frm/thread/28375b...](http://groups.google.com/group/ceug/browse_frm/thread/28375bca0277a16b)

\- scala: lots: Akka, scalaz, lift threads, STM, Bagwell's data structures

\- clojure: special purpose mutability: transients will be old hat, Hickey's
working on "cells", (lately he's been coding reify/deftype/defrecord)

\- F#: lots, I haven't been tracking, and i just saw the cheapest Vis studio
2010 is $800(?!)

\- haskell (GHC) CHP's, STM, lots other stuff

(Suppose i oughter blog about)

~~~
gtani
OK, let me try to be more helpful. Here's good backgrounders

<http://www.tbray.org/ongoing/What/Technology/Concurrency/>

[http://www.sauria.com/blog/2009/10/05/the-cambrian-period-
of...](http://www.sauria.com/blog/2009/10/05/the-cambrian-period-of-
concurrency/)

[http://groups.google.com/group/clojure/browse_thread/thread/...](http://groups.google.com/group/clojure/browse_thread/thread/5c7a962cc72c1fe7?hl=en)

[http://blogs.azulsystems.com/cliff/2008/09/jvm-language-
su.h...](http://blogs.azulsystems.com/cliff/2008/09/jvm-language-su.html)

<http://wiki.jvmlangsummit.com/pdf/36_Click_fastbcs.pdf>

\---------------------

also recommended: Herlihy/Shavit book, blogs by Sutter and Duffy,

[http://www.amazon.com/Art-Multiprocessor-Programming-
Maurice...](http://www.amazon.com/Art-Multiprocessor-Programming-Maurice-
Herlihy/dp/0123705916)

<http://herbsutter.com/>

<http://www.bluebytesoftware.com/blog/Default.aspx>

------
dadkins
> A Consistent/Available system means that reading and writing always works
> the way you expect, but if one node fails the whole system stops working.

I've seen this mistaken statement several times now and it really bugs me. A
consistent/available system can't tolerate partitions, i.e. a split in the
network. However, it can certainly tolerate a single failure and remain
consistent and available. That's the whole point. A trivial system with these
properties is one that replicates every update to all available nodes and
requires reads to get matching results from at least half of the nodes. Paxos
is another example.

~~~
aristus
You've got a good point, and I'm not satisfied with that section. Can you
think of a real-world example of a network partition? Maybe a parade that
bisects the city?

~~~
dadkins
A washed out bridge.

~~~
aristus
I like it. We have a winner. Thank you!

"Think of a parliment that must have more than half of members present in
order to hold a vote. If too many can't make it, say because a flood washes
out the bridge, a quorum can't be formed and business can't proceed."

------
iheartmemcache
Relevant complementary reading (Widefinder implemented in Clojure):
<http://meshy.org/2009/12/13/widefinder-2-with-clojure.html>

------
daniel02216
This author is really good at analogies.

~~~
sharpn
Yes, my favourite:

"In essence, transactional memory allows threads to ask for forgiveness
instead of permission."

~~~
wheaties
Good article. I'm still waiting to hear back so I can have y shot. I wanted to
give STM a try too.

------
j-g-faustus
Thanks for a nice overview. I have by and large managed to bypass concurrency
issues so far, but these days an i7 CPU runs 8 threads and a run-of-the-mill
dual socket Xeon could have 24 threads, so I suppose I'll just have to bite
the bullet in order to get anywhere near the performance even a single box can
supply.

Where would goroutines, from Google's Go (<http://golang.org/> ), fit in here?

My understanding is that goroutines are pretty much the same as Erlang message
passing, except that Erlang messages can work across multiple computers, while
goroutines are restricted to one computer (same memory space). Is this
correct?

~~~
aristus
I don't know much about Google Go (or coroutines, for that matter), but from
the description it sounds like you are correct.

------
jfmiller28
Its not only languages, but data structures that need to change. C.f. this
video (<http://vimeo.com/6624203>) from ICFP '09

------
Oranj
Can someone mirror it outside Facebook?

~~~
aristus
[http://carlos.bueno.org/2010/04/dismal-guide-to-
concurrency....](http://carlos.bueno.org/2010/04/dismal-guide-to-
concurrency.html)

The original link is viewable without needing to be logged-in to FB, as far as
I can tell.

------
DTrejo
Will this change with quantum computing and entanglement?

 _You can't avoid it by using electrons instead of street urchins. It's
impossible for an event happening in one place (eg data changing inside one
computer or process) to affect any other place (eg other computers or
processes) until the information has had time to travel between them._

~~~
jessriedel
No. Causality can only propagate at the speed of light, with or without
quantum mechanics.

~~~
ableal
My understanding is that 'entanglement' is like having two urchins each draw a
ball from a bag with a black/white pair. One urchin goes East, the other goes
West.

Assuming they arrive at A and B, respectively, this may be useful somehow. But
it cannot really communicate _new_ information from A to B.

(Unless the balls are carried _unobserved_ , and one of the recipients - by
staring _real_ hard ? - can somehow choose the color of the ball he is
unwrapping.)

~~~
jessriedel
Your analogy is correct inasmuch as the urchins cannot communicate for the
same reason the Alice and Bob, each with one particle of an entangle pair,
cannot communicate. But it can be shown by very clever experiments that the
future statistical observations of Alice and Bob _cannot_ be explained by
assuming each had a particle with properties fixed when the two parted ways.
Entanglement is very subtle.

------
dalton
tl;dr

~~~
gphil
you missed out, this was worth reading

~~~
eru
And while it's ok not to read stuff, he shouldn't add noise to the discussion.
We don't care.

------
runT1ME
Does...this article have e thesis? Or is this just sort of an overview of
stuff...

