[ruby-core:44307] Re: Questions about thread performance (with benchmark included)

On Tue, Apr 10, 2012 at 5:33 AM, Urabe Shyouhei <[e-mail]> wrote:
> On 2012年04月09日 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/