From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-28T04:01:43+09:00
Subject: Re: Ruby Threads...

------=_Part_305391_6251348.1148756500280
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>>You probably mean "Thread.critical" or "Thread.exclusive", and not
"synchronize", at least in the context of ruby. (There is a
Mutex#synchronize and of course that does require you to think about
synchronization sets and ordering.)

No, I mean Mutex#synchronize and its equivalents in Java and Python. Proper
synchronization design is a fine art, and highly hardware and OS dependent.
The simplicity of #synchronize encourages people not to learn it very
deeply. As I said upthread, the thread-support constructs provided by Ruby,
Python, Java and similar languages seem designed to facilitate the goal of
making threaded programming easier to do. This is of course a fine goal in
itself. But using threads to make programs faster and more concurrent is a
very different goal, one which IMO is NOT well supported by Java or any of
the agile languages.

>>>Doesn't have one and doesn't need one, as long as threads are green.
But, someday, when ruby has native threads, it will need spin locks.

Fair enough as far as it goes. But green threads mean you can't take
advantage of multiprocessor hardware at all. (Python has the same
shortcoming, but for a different reason.) So as long as we're clear on
Ruby's goals (grace and ease of cross-platform development) and its
non-goals (performance and scalability), you don't need the more powerful
thread-handling constructs, and for now there's nothing wrong with that. Bu=
t
all of this changes when serious multicore hardware like the Cell processor=
s
become the norm. At that point, we'll all need to get a lot better at
programming multithreaded, multiprocess or event-driven, and our language
systems will have to evolve accordingly.


On 5/27/06, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
>
> Francis Cianfrocca wrote:
> ...
> > Threads can be used for two basic purposes: to make your programs run
> > faster, or to make them easier to write. Ruby's (and Java's) threads
> seem
> > designed primarily to facilitate the latter. You can easily imagine
> several
> > kinds of problems that are easier to model if you have access to
> relatively
> > independent flows of control. Thus both languages have the "synchronize=
"
> > method, taking an arbitrary code block, which makes it easy to lock
> > relatively large chunks of code in "critical sections" without having t=
o
> > really design proper synchronization sets.
>
> You probably mean "Thread.critical" or "Thread.exclusive", and not
> "synchronize", at least in the context of ruby. (There is a
> Mutex#synchronize and of course that does require you to think about
> synchronization sets and ordering.)
>
> > But to effectively use threads for higher performance and concurrency
> > requires a large amount of experience and understanding, much of which
> > takes
> > platform dependencies into account. For just one example, I would want
> to
> > use a spin lock in some situations, if I'm running on a multi-processor
> > machine on certain hardware platforms. Ruby doesn't have one.
>
> Doesn't have one and doesn't need one, as long as threads are green.
> But, someday, when ruby has native threads, it will need spin locks.
>
> --
>       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>

------=_Part_305391_6251348.1148756500280--