[Shootout-list] Re: ring of processes

Aaron Denney wnoise@ofb.net
Sun, 3 Oct 2004 18:24:12 +0000 (UTC)


On 2004-10-03, Raymond Racine <rracine@adelphia.net> wrote:
> I am not clear on the ring of process test.
>
> I am reading the test description as follows for a slave process.  By
> interpreting the test description, I mean reading the pseudo code and
> its accompanying text.
>
> In the algo below, "I" is an arbitrary slave process.
>
> - If I receive a hipri msg, send it on immediately after verifying the
> proper sender.  Increment my count of hipri msgs received.  

check.

> - As long as my hipri message count is < 10, I am in the state of hard
> working.  (See paragraph 4. para 2 in the description.)

check.

> - If the number of hipri msgs I have received is < 10, then ignore
> incoming lopri messages.  But I am not to discard them, as they are to
> be processed later when I am no longer hardworking (hipri count >= 10)

check, mostly.

> - When I have received 10 hipri msgs I am no longer hard working.  I now
> continue to process hipri messages AND now start processing my lopri
> msgs (which were buffered) by sending them on unverified as to the
> sender.

check, mostly.  You are no longer hardworking after 10, but you resume
hardworking immediately after processing lowpriority messages.

Now there's still some wiggle room there -- before resuming "hard-work",
do I process:
(a) at most one low-priority message, if there is one waiting.
(b) any currently waiting low-priority messages.
(c) exactly one low-priority message, waiting for it if necessary.

As far as I understand the Erlang implementation, it does (a).
The Haskell implementation does (c).

Due to the structure of the test, (a) and (b) should be
indistinguishable, and (c) very close.

Less clear to me is what the master process should be doing during
this time.

The Haskell implementation sends a Hi, and a low, and then relays
10N high-priority messages and N low-priority messages, in order
10 high, 1 low.

I don't entirely understand what the Erlang implementation does, but
it looks like it:

repeat N times: 
        send high, low
        wait for high
        every 10'th high received, check for and discard any lows.

I'd really like it if the test text could be updated.

Hmm, on rereading, it looks like the slaves do this as well:

repeat:
        repeat 10 times
                send high, low,
                wait for high
        repeat until no lows waiting:
                read low, and discard it.

Any Erlangers out there that can confirm my reading?

Should I go ahead and post an updated Haskell version that does this?

-- 
Aaron Denney
-><-