On 7/19/06, M. Edward (Ed) Borasky <znmeb / cesmail.net> wrote:
> anmus wrote:
> > Hi All,
> >
> > The recent IEEE Computer society magazine 'Computer' May 2006 has a
> > thought-provoking article on threading and concurrency (p. 33).
> >
> > The author has three points:
> > 1. Threading is an error prone method of parallelizing a program.
> > Basically, his thesis is that thread packages support
> > non-deterministic coding and then adds methods of constraining the
> > non-determinism, and that such methods are brain-twistingly difficult
> > to write and read, difficult to test, and have latent bugs that don't
> > appear for years which are correspondingly impossible to duplicate.
> >
> > 2. Better methods of expressing concurrency exist, have been
> > implemented in many obscure languages, and still don't have mainstream
> > acceptance.
> >
> > 3. The author advocates use of 'coordination' or 'composition'
> > languages on top of existing general purpose languages to express
> > concurrency. These coordination languages still have a lot of work yet
> > to be done. My thought is perhaps Ruby can express concurrency cleanly
> > _without_ needing another language.
> I read the article and somewhat vaguely remember what the author
> recommended. I think "still have a lot of work yet to be done" is a
> gross understatement. :)
>
> > I thought this idea might appeal to Matz, language-aficionado that he
> > is, and that Ruby has demonstrated with Rake and Rails that not having
> > multiple languages in a development environment has benefits.
> >
> > My point in posting this message is to ask the Ruby community if it is
> > worth thinking about laying some foundations in Ruby 2.0 and YARV to
> > elegantly support other methods of expressing concurrency. Perhaps
> > this work won't show results until Ruby 3.0, but reserving some
> > keywords in the grammar and some hooks in the VM may yield dividends
> > in the future.
> Uh ... the primitives need to be in the OS for most
> "concurrency/parallelism" implementations.

I've got an SMP kernel.

> Keywords and virtual machines
> come after that. And for the primitives to be in the OS, they need to be
> in the hardware.

I've got a dual core processor.

> The paradigms supported by today's hardware and
> operating systems are the paradigms that have a track record for the
> most part.

Some support for parallelism seems to be already in place at that OS
and hardware levels.  I think the point of the article (which I only
read a summary of) was that we need better ways of describing
parallelism (better ways than threads).

>
> > It is clear to me that single processor machines are becoming quaint,
> > and that the new norm in desktop machines will be multi-core,
> > multi-chip SMP and NUMA machines along with clusters for servers.
> And the stories I'm seeing in the trade press are that "parallel
> programming" is no easier today than it was when Gene Amdahl first
> published his law. There aren't any silver bullets.
> >
> > In this new environment, if Ruby can seamlessly and cleanly take
> > advantage of available concurrent resources, it will be a huge win for
> > Ruby over other popular languages. My hope is that the Ruby VM will
> > take care of each architecture's concurrency ugliness behind the
> > scenes, leaving the fun stuff in front.
> Strangely enough, I don't recall ever seeing a *real* programming
> language, to be distinguished from academic ones, that ever handled
> parallelism in a manner other than as calls to run-time libraries. Ruby
> already has that.
>

In the hardware world there are HDLs (hardware description languages)
which model  parallelism using an RTL/dataflow model.  Oddly enough,
the hardware folks are trying to figure out how to use C/C++ to model
hardware.  I'm wondering if they're going the wrong direction; C/C++
don't seem to be a good fit for hardware design from what I've seen so
far.  Maybe we need to inroduce dataflow concepts into general purpose
programming languages. (project plug: See RHDL:
http://rhdl.rubyforge.org/ ).

The basic idea is that in an HDL everything is happening at once; all
statements outside of a process block execute concurrently.  Inside a
process they execute as they would in a normal programming language,
but all of the processes are considered to be executing in parallel.
processes get triggered by changes in signals.  Of course HDL
simulators often make use of threads or continuations (RHDL uses
continuations which in turn are implemented as threads in Ruby).

Hardware in inherently parallel.  You can think of logic gates as
being simple little processors.  Outputs change when inputs change.
dataflow.  That's why HDLs were developed in the mid 80's to model
hardware.

Phil