[nem-en] Re: Re: Re: language shootout: cheap-concurrency (Dmitry Ivankov)

Micky Latowicki biosap at gmail.com
Mon May 7 20:30:39 CEST 2007


> One question: why it is called concurrency?
> As far as I understand the task is to use general concurrency mechanisms.

Concurrency, as the term is used in this benchmark, means that you
write something that looks sequential yet runs at the same time as
other sequential things.

In this case, the thing whose code  looks sequential - the thread - is
the result of the IncrementorThread function. Its structure is
isomorphic to that of a message loop, where a thread repeatedly waits
for an int message in its input channel, does some work, and then
emits a message to its output channel.

Consider these two functions, the first of which may be the body of a thread:

def IncrementorThread(inChannel, next) {
   while(true) {
      x = inChannel.wait();
      next.put(x+1)
   }
}

Compare this with an earlier version of my code:

        def IncrementorThread(next)
            co.Waiting((x)=>{ // start of loop
                def nextNext = next.put(x+1);  // body of loop
                IncrementorThread(nextNext) // return to start of loop
            })

These functions both wait for input, increment it, then emit it, and
loop. They can both be run concurrently with other functions, except
that the latter can do so very cheaply - no need for an OS-level
thread.

This approach has the main advantages that come with lightweight
threads - the thread's code is concentrated in one place, there's no
fear of race conditions, and switching between "threads" is fast.

However, judging by the reception similar implementations of the
benchmark have received, I now think that such implementations aren't
conventional enough to be regarded as unambiguously concurrent.

I guess I'll write another implementation, one that uses yield, and
then it will be just as visibly concurrent as the python
implementation that was accepted to the benchmark. It's too bad,
though - I think using explicit closures, rather than the implicit
ones created by yield, is just as convenient and more flexible.



More information about the devel-en mailing list