[BLOG] Concurrency models

[Pit Capitain]

In this blog post


http://moonbase.rydia.net/mental/blog/programming/concurrency-five-ways.html

MenTaLguY shows how to implement a thread-safe queue using five
different concurrency models found in Ruby and other languages. He shows
how they would look like in Ruby and explains how they would work.

Regards,
Pit

 

[pat eyler]

In this blog post


http://moonbase.rydia.net/mental/blog/programming/concurrency-five-ways.html

MenTaLguY shows how to implement a thread-safe queue using five
different concurrency models found in Ruby and other languages. He shows
how they would look like in Ruby and explains how they would work.

I enjoyed this post too. It's one of the ones that's helping me get a handle
on the concurrency options that are being considered for rubinius. They're
currently leaning toward STM. MenTaLguY also shared a great list of other
options at:
http://on-ruby.blogspot.com/2007/01/serial-rubinius-interview-episode-v.html

 

[gwtmp01]

I enjoyed this post too. It's one of the ones that's helping me
get a handle
on the concurrency options that are being considered for rubinius.

What does this mean for portability between different implementations
of Ruby?
I tend to think that concurrency primitives/semantics need to be part
of the
language itself and so I'm not sure I like the idea of 'rubinius
concurrency
options' vs. 'Ruby concurrency options'.

Gary Wright

 

[pat eyler]

What does this mean for portability between different implementations
of Ruby?
I tend to think that concurrency primitives/semantics need to be part
of the
language itself and so I'm not sure I like the idea of 'rubinius
concurrency
options' vs. 'Ruby concurrency options'.

The primary discussion in rubinius' case is about how concurrency will
be implemented internally -- e.g., how do you make arrays thread safe?
STM seems to be the leading candidate for what will be working under
the covers.

I'm guessing that STM will also be available for people who want to
use it for their own concurrency needs, and the library that provides
it will hopefully be available for all of the Ruby implementations.

 

[gwtmp01]

The primary discussion in rubinius' case is about how concurrency will
be implemented internally -- e.g., how do you make arrays thread
safe?
STM seems to be the leading candidate for what will be working under
the covers.

Ah. That makes it much clearer. Thanks.

Does this mean that there is already an implicit understanding that some
methods in the core Ruby classes are inherently thread safe? If so are
*all* core methods thread safe? Is that by design or accident? I doubt
that the entire standard library is thread safe but perhaps large
parts are?

This is the sort of thing that should probably be quite clear in any
written specification of Ruby.

I'm just thinking out loud. With the expanding number of Ruby
implementations
it now becomes more important to make these sorts of assumptions
explicit
rather than being implicitly defined by the behavior of the original
'primary' Ruby implementation.

Gary Wright

 

[Wilson Bilkovich]

Ah. That makes it much clearer. Thanks.

Does this mean that there is already an implicit understanding that some
methods in the core Ruby classes are inherently thread safe? If so are
*all* core methods thread safe? Is that by design or accident? I doubt
that the entire standard library is thread safe but perhaps large
parts are?

They definitely are not. Given that fine-grained locks in library code
do not compose, it's going to take some work to make the whole stdlib
thread-safe once native threads are available.
In Rubinius, we are aiming for STM, because it solves the composition problem.
I've been meaning to poke around and see how YARV is planning to fix this.

 

[Daniel Berger]

In this blog post


http://moonbase.rydia.net/mental/blog/programming/concurrency-five-ways.html

MenTaLguY shows how to implement a thread-safe queue using five
different concurrency models found in Ruby and other languages. He shows
how they would look like in Ruby and explains how they would work.

Very interesting stuff, especially in light of the fact that I was just
going over the Fortress spec the other day, and I've already spotted
one similarity:

atomic do
...
end

Yep, the Fortress syntax and the syntax Mentalguy came up with are
identical. Coincidence? I think not.

Will we be getting parallel for loops, too?

Regards,

Dan

 

[gwtmp01]

They definitely are not. Given that fine-grained locks in library code
do not compose, it's going to take some work to make the whole stdlib
thread-safe once native threads are available.

What does 'They' refer to in your comment? The core classes or the
standard
library? Are there non-thread safe methods in the core classes? I was
trying to distinguish between the two groups of classes in my comment.

Gary Wright

 

[Wilson Bilkovich]

Very interesting stuff, especially in light of the fact that I was just
going over the Fortress spec the other day, and I've already spotted
one similarity:

atomic do
...
end

Yep, the Fortress syntax and the syntax Mentalguy came up with are
identical. Coincidence? I think not.

Actually, that syntax is from the original paper that introduced STM.
Nobody in Ruby-land made it up. Heh.

 

[Wilson Bilkovich]

What does 'They' refer to in your comment? The core classes or the
standard
library? Are there non-thread safe methods in the core classes? I was
trying to distinguish between the two groups of classes in my comment.

I meant the stdlib. The core classes are largely written in C, and
wrapped by various locks (the pieces I have examined, at least).

I'm not claiming the whole stdlib is a farrago of non-thread-safety.
Just that it definitely isn't intended to be a thread-safe toolkit,
and will need attention Before We Are Done.

 

[Benjohn Barnes]

I enjoyed this post too. It's one of the ones that's helping me
get a handle
on the concurrency options that are being considered for rubinius.
They're
currently leaning toward STM. MenTaLguY also shared a great list
of other
options at:
http://on-ruby.blogspot.com/2007/01/serial-rubinius-interview-
episode-v.html

I'm also extremely interested by STM. I've been reading the paper
about it, and I like it a lot.

Something I've been very interested in for about 12 years is some
research by the Empirical Modelling Group at Warwick University (UK).
They have this idea of dependency driven systems. Basically, imagine
that your programming language gives you spreadsheet like semantics
so that if a computation is dependent on some state, you can
automatically have that computation be re-run if any of its input
state changes. Unlike Model View Controller, you don't need to do any
subscription, it all just happens. The Warwick group implemented
these ideas in a number of experimental languages, notably Eden. I
now see nothing to stop the ideas being used in conventional
languages: they can be provided via an API.

Dependency based programming seems to remove a great deal of code and
cache state from programs - the language or API supports this for
you. It leads to simpler programs and makes them much more
composeable and mutable: you can easily stick bits of program
together without having designed them for such a purpose, and
programs parts can easily be re-used and modified.

The STM ideas seem to overlap enormously with Warwick dependency
work. A few extensions to the STM in the paper will let you know when
a transaction has become "stale" because some of the inputs it
observed have changed. Stale transactions should be re-run, and the
user shown their new output.

It's my belief that a bit of fundamental infrastructure we're missing
is an API that provides a distributed, STM. I think it also needs a
few extensions:

Versioning of data (Very useful anyway, but I think will also be
useful for allowing different parts of the global system to be
somewhat out of sych. which each other, which is probably essential
for many distributed applications),

De-centralisation (I think it's critical that anyone can see the
world as they wish, and share that view with anyone else. Critically,
this allows independent development, and for a kind of market place
of interfaces and data. It means you don't need centrally agreed
schema, things can evolve without needing to throw away your old data
and start again).

Lots of other things like signing / authentication / encryption /
relational queries would also be really good, but I'm not so
convinced that they're critical.

Sorry for rather a long post, but I hope it makes some sense.

Cheers,
Benjohn