Beyond threads? Better concurrency methods?

[Ron M]

Erlang doesn't count? True, I don't know of anyone using it besides
Erikson...

A couple other notable projects built with Erlang are
the "Wings 3D" [1,2,3] 3D modeling package and the
"ejabberd" [4] database-backed Jabber server. Earlier this year
Jabber.org (one of the larger jabber servers with 180K users)
started using the Erlang based server for its own use[5], so
it's a pretty mature product.

Erlang is actually a pretty nice general purpose language; and
indeed was designed to support parallelism without threads[6].

I'd have to say Erlang's an excellent answer to Ed's comment.



To Ed's "real programming language .. that handled parallelism in
a manner to calls other than calls to run-time libraries", doesn't
C with OpenMP also count?

#include <omp.h>
int main(int argc, char *argv[])
{
int i, a[100];
#pragma omp parallel for
for (i=0;i<100;i++) a= 2*i;
return 0;
}

Though admittedly I've only seen OpenMP in academic projects so far.





[1] http://www.wings3d.com/
[2] http://www.wings3d.com/gallery.php
[3] http://en.wikipedia.org/wiki/Wings_3D
[4] http://en.wikipedia.org/wiki/Ejabberd
[5] http://support.process-one.net/doc/display/NEWS/2006/03/06/Jabber.org+adopts+ejabberd
[6] http://en.wikipedia.org/wiki/Erlang_programming_language

 

[Isaac Gouy]

A couple other notable projects built with Erlang are

-snip-


The Erlang user conferences and workshops might give a better idea of
what Erlang is being used for
http://www.erlang.se/euc/index.shtml
http://www.erlang.se/workshop/index.shtml


Erlang in Banking and Financial Switching
http://www.erlang.se/euc/03/

 

[Csaba Henk]

Erlang's sort of a strange one. Obviously, it can't be called
academic, and the programming model is entirely based on concurrency,
but at the same time, it doesn't support native threading. I've always
thought that is a strange choice. They have really fast user-space
threading, but it will never use multiple processors unless you're
running multiple Erlang VMs, and then you have to explicitly start your
thread on the VM of your choice, from what I understand.

I read somewhere about Erlang that the next release of the VM will
support using OS threads for pooling Erlang processes transparently.

I can't recall though when the referred statement was written -- it's
possible that it was written long before and that "next release" has
came to reality since then.

Still, I love
the language. I wish ruby allowed overloading of the ! operator, just
so I could implement a ruby thread wrapper that could accept messages
with Erlang syntax

Well, in Erlang it's a principle that processes may communicate _only_
via the messaging interface. It's achieved by the (almost) pure
functional semantics. Data is never modified in-place, always copied. A
function (in particular one ran in a process) can see only the values
which were passed to it as arguments (by value).

[Disclaimer: AFAICS, IANAEH]

I wonder how would you enforce this strong separation in ruby... maybe
_why-s shiny Sandbox could be made use of?

Regards,
Csaba

 

[Isaac Gouy]

I read somewhere about Erlang that the next release of the VM will
support using OS threads for pooling Erlang processes transparently.

I can't recall though when the referred statement was written -- it's
possible that it was written long before and that "next release" has
came to reality since then.

-snip-

Yes, see http://www.erlang.org/doc/doc-5.5/doc/highlights.html

 

[M. Edward (Ed) Borasky]

You should take a look at Occam-PI
(http://www.cs.kent.ac.uk/projects/ofa/kroc/) which is a marriage of
PI-Calculus and OCCAM...

Yes, I should take a look at that. Although ... CSP (Occam/Hoare) and
CCS (Milner) cover pretty much the same ground, and the PI-Calculus is a
direct descendant of CCS. I'm wondering what CSP can do that the
PI-Calculus can't.

 

[tsuraan]

I read somewhere about Erlang that the next release of the VM will

-snip-

Yes, see http://www.erlang.org/doc/doc-5.5/doc/highlights.html

Awesome! Thanks!

 

[tsuraan]

Well, in Erlang it's a principle that processes may communicate _only_

via the messaging interface. It's achieved by the (almost) pure
functional semantics. Data is never modified in-place, always copied. A
function (in particular one ran in a process) can see only the values
which were passed to it as arguments (by value).

How (almost) pure functional? I haven't used Erlang much, but it seems
to be totally pure-functional from what I can tell. They do use
looping threads to keep state, so side-effects are possible that way,
but is there a way to override defined variables?

[Disclaimer: AFAICS, IANAEH]

I wonder how would you enforce this strong separation in ruby... maybe
_why-s shiny Sandbox could be made use of?

For the places where Erlang is supposed to be used, I suppose that the
extreme separation they use is a really good idea, but I'd love to just
have the syntax available in Ruby. I tend to design a lot of my
programs as processes sending each other messages right now (mind
polluted by erlang, I guess), and just being able to have some nice
syntax for that in ruby would make me quite happy.

--jay

 

[Csaba Henk]

How (almost) pure functional? I haven't used Erlang much, but it seems
to be totally pure-functional from what I can tell. They do use
looping threads to keep state, so side-effects are possible that way,
but is there a way to override defined variables?

* As I heard, you are not prohibited to play dirty tricks with the
few globally accessible data structure like the process table
(although doing that is not considered to be good style).

* IIRC message passing is considered a side effect generating call. I could
imagine a concurrency semantics where it's not a side effect; I don't
see how Erlang's semantics relates to that.

* The big beast: I/O. A purely functional language must somehow encode
I/O as environment (world state) passing, like Haskell does it with
monads and Clean with unique types.

Erlang doesn't want to sink into such abstractions, it just does I/O
as usual.

For the places where Erlang is supposed to be used, I suppose that the
extreme separation they use is a really good idea, but I'd love to just
have the syntax available in Ruby. I tend to design a lot of my
programs as processes sending each other messages right now (mind
polluted by erlang, I guess), and just being able to have some nice
syntax for that in ruby would make me quite happy.

I don't see into your mind, but maybe what's there is closer to the
idea of coroutines than to CSP style models.

Regards,
Csaba

 

[anmus]

Interesting. But I don't have IEEE Computer magazine at hand. Could
anyone point me further information about this 'coordination'?

matz.

Try starting with this paper:

Coordination models and languages
G.A. Papadopoulos; F. Arbab;
1998, SEN-R9834, ISSN 1386-369X

http://www.cwi.nl/ftp/CWIreports/SEN/SEN-R9834.pdf
or
http://www.cwi.nl/ftp/CWIreports/SEN/SEN-R9834.ps.Z


-Robert

 

[Dido Sevilla]

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.

There's the Limbo programming language, invented by Rob Pike, Phil
Winterbottom, and some of the other guys responsible for Plan 9, used
in the Inferno operating system [1]. It essentially implements
communicating sequential processes: it incorporates typed
communication channels between processes as a language primitive, and
provides built-in mechanisms for using them for synchronization and
communication. It's an interesting piece of work, and I for one would
like to see Ruby with similar features in the future.

[1] www.vitanuova.com

 

[ara.t.howard]

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.

There's the Limbo programming language, invented by Rob Pike, Phil
Winterbottom, and some of the other guys responsible for Plan 9, used
in the Inferno operating system [1]. It essentially implements
communicating sequential processes: it incorporates typed
communication channels between processes as a language primitive, and
provides built-in mechanisms for using them for synchronization and
communication. It's an interesting piece of work, and I for one would
like to see Ruby with similar features in the future.

[1] www.vitanuova.com

fortytwo :~ > cat a.rb
require 'slave'

class ServerA
def meth() 40 end
end

class ServerB
def meth() 2 end
end

sa, sb = [ServerA, ServerB].map{|c| Slave.new c.new}

p sa.pid
p sb.pid

a, b = sa.object, sb.object

p(a.meth + b.meth)


fortytwo :~ > ruby a.rb
26206
26207
42


-a

 

[Csaba Henk]

require 'slave'

AFAICS slave.rb's operation is based on fork(2).

So a slave based code is not using a language feature but an OS feature;
it tells nothing (or very little) about the expressive power of the
language. And it neither performs well as a concurrency implementation.

Regards,
Csaba

 

[ara.t.howard]

AFAICS slave.rb's operation is based on fork(2).

So a slave based code is not using a language feature but an OS feature;
it tells nothing (or very little) about the expressive power of the
language. And it neither performs well as a concurrency implementation.

true all. nevetheless it's an alternative to threads.

regards.

-a