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
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:
On Ruby: Serial rubinius Interview: Episode V
On 1/18/07, Pit Capitain <pit@capitain.de> wrote:
Regards,
Pit
--
thanks,
-pate
-------------------------
Pit Capitain wrote:
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
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
On Jan 18, 2007, at 7:56 AM, pat eyler wrote:
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.
Actually, that syntax is from the original paper that introduced STM.
Nobody in Ruby-land made it up. Heh.
On 1/18/07, Daniel Berger <djberg96@gmail.com> wrote:
Pit Capitain wrote:
> 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
...
endYep, the Fortress syntax and the syntax Mentalguy came up with are
identical. Coincidence? I think not.
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
On 18 Jan 2007, at 12:56, pat eyler wrote:
On 1/18/07, Pit Capitain <pit@capitain.de> wrote:
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:
On Ruby: Serial rubinius Interview: Episode V
> 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'.
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.
On 1/18/07, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
On Jan 18, 2007, at 7:56 AM, pat eyler wrote:
Gary Wright
--
thanks,
-pate
-------------------------
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
On Jan 18, 2007, at 11:19 AM, pat eyler wrote:
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.
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.
On 1/18/07, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
On Jan 18, 2007, at 11:19 AM, pat eyler wrote:
> 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?
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
On Jan 18, 2007, at 1:07 PM, Wilson Bilkovich wrote:
On 1/18/07, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
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.
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.
On 1/18/07, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
On Jan 18, 2007, at 1:07 PM, Wilson Bilkovich wrote:
> On 1/18/07, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>> 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.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.