On Tue, Apr 10, 2012 at 5:33 AM, Urabe Shyouhei <shyouhei / ruby-lang.org> wrote:
> On 2012ǯ0409 22:37, Rodrigo Rosenfeld Rosas wrote:
>> I don't think any threaded application can be lock-free, including a language interpreter. But having locks (instead of a single global lock) doesn't mean you can't use the full power of processors.
>
> Technically speaking, there are reasons why MRI cannot take this
> approach. One reason for it is that MRI's GC needs a giant locking
> because no modifications to any objects shall be allowed during GC
> (this restriction can theoretically be weakened, but in practice it is
> very hard).

Right.  One just needs to look at the 7 years Sun needed to take G1
from prototype to production ready.

> Another reason is that most extension libraries are not
> designed to be multi-thread ready; for instance the SQLite database
> does not support multiple transactions per a connection, which
> effectively kills multi-threaded usage.
> cf: http://www.sqlite.org/faq.html#q6

I don't think this is a good argument: in Java land most JDBC
connection implementations are not multithreaded (in fact it's usually
more a restriction of the backend) and all JEE application servers
happily employ multithreading.  It's not too hard to ensure things are
thread local which cannot be used concurrently.

Also, there is the core library which would of course have to be
thread safe if MRI gets rid of GIL and which provides enough
functionality to create useful MT applications.

> Someone with skills is always welcomed!

Now I only need the time... :-)

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/