[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: [BLOG] Concurrency models
From:       "Wilson Bilkovich" <wilsonb () gmail ! com>
Date:       2007-01-18 18:07:33
Message-ID: d4e4955b0701181007j2a115ab0oecb345b28bce33d () mail ! gmail ! com
[Download RAW message or body]

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?

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.

[prev in list] [next in list] [prev in thread] [next in thread]