From: Yohanes Santoso <ysantoso-rubytalk@...>
Date: 2005-07-30T01:05:27+09:00
Subject: Re: Ruby and threads

"Adam P. Jenkins" <thorin@theshire.com> writes:

> Yohanes Santoso wrote:
>> "John Wells" <lists@sourceillustrated.com> writes:
>>
>>>Guys,
>>>
>>>Was looking through the forums at ruby-ide.com when I noticed the
>>>following comment:
>>>
>>>"Unfortunately i can't use ruby for scripting/extending/implementing as
>>>ruby does not work with multiple native threads and i already have one
>>>ruby thread that is doing the background parsing."
>>>
>>>Can anyone elaborate on this?  How does it effect folks developing in
>>>Ruby, and curiously, why does Python seem to support it and Ruby
>>>doesn't?
>> I can come up with only two significant downsides of green threading
>> that ruby has:
>> 1. inability to use multiple cpus to run multiple threads,
>> 2. blocked process.
>> (2) is usually caused by disk io waiting for disk readiness. this is
>>     not monitorable in most unix (windows too?). the whole process
>>     would block until the disk is ready.
>> (2) is also caused by certain functions in some c extension
>> libraries.
>> python's supports for native threading effectively eliminates these
>> two downsides, but also introduce another downside. threads executing
>> python code would need to obtain the global interpretter lock. This
>> means at any given moment, there is still only one thread executing
>> python code.
>
> This certainly isn't an inherent problem with native threads; there is
> no reason in principle that an interpreted language couldn't let
> multiple threads execute simultaneously if the interpreter were
> written correctly.  

Adam,

You are right that this isn't an inherent problem with native
threads. There are language implementations that use interpreted
technique that locks only the relevant interpreter state data, and not
the whole interpreter. These implementations would be able to take
advantage of multiple CPUs in a 'better' way than an implementation
that locks the whole interpreter. Examples of these implementations
would be sun's jvm which can interpret the bytecode in multiple CPUs
concurrently.

<sidebar>languages are neither compiled nor interpreted; but an
implementation of a language is compiled or interpreted or both
(e.g. JIT))</>

> If what you say is true, that only one Python
> thread can be executing at a time, then Python still can't really take
> advantage of multiple CPUS.
>
> Adam

What I said before applies to pre-2 python. I am not sure what's the
current state is. Even if it is still the same, it would still be able
to take advantage of multiple CPUs, although not directly, as there
are other things to do beside executing code.

For example, think of reading from a socket. At the OS level, that
would involve copying of memory from the eth card's memory to the main
RAM (unless your eth card&driver are doing DMA). Doing reads from two
different native threads would likely result in two CPUs doing the
copying.

While with current ruby implementation, there is only one copying
going on at a time.

You can test whether current python implementation still use a global
interpreter lock or not by trying to span multiple threads, each doing
some CPU-intensive computation (e.g. repeatedly increasing the value
of some thread-local variable) on a MP machine, and then comparing the
result with the same program on the same MP machine with less number
of CPUs activated.

I can't do the above test since I don't have access to a MP machine
anymore. So, I'm waiting for your response.

Yours,
YS.



>
>> In addition, the cost of acquiring the lock increases
>> with the number of threads. But this setup eliminates (1) and (2).
>> YS.
>>
>>>Thanks for your insight!
>>>
>>>John
>>