M. Edward (Ed) Borasky
7/20/2006 4:09:00 AM
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. Keywords and virtual machines
come after that. And for the primitives to be in the OS, they need to be
in the hardware. The paradigms supported by today's hardware and
operating systems are the paradigms that have a track record for the
most part.
> 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.
Well, actually, there was *one* ... Occam for the Transputer. Some
companies actually built products around this, although they were not
economically viable. Ruby seems to be too well established for it to
suffer this unhappy fate.
> Yes, I'm posting this essentially anonymously. I'm new to Ruby, and
> rusty at coding and threading. I'm intrigued by the idea of having fun
> again and I want Ruby to be the best language it can be. I did search
> the archives for discussions of concurrency and parallelism - I didn't
> find very much. I also want to be able to attend Ruby events without
> needing a paper bag on my head if it turns out that this is a
> pointless post. I trust the community won't flame me too badly.
No, it's not a pointless post by any stretch of the imagination. I think
most of us over a certain level of experience in programming have these
dreams. In my own career, so far I've had the dreams of automatically
proving programs correct, widespread adoption of formal semantics in
programming languages, functional languages and programming styles
dominating the practice, literate programming, the ability to write
programs faster, etc. All of these dreams have fallen to the tyranny of
"good enough", and I suspect "seamless supercomputing" is another one.
So I write my code the way I know how, hope that others can read it, try
to keep it simple enough that I can convince myself it's correct, and
try to reserve the time to refactor.