From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Concurrency and message passing with Newsqueak
Date: Sat, 19 May 2007 12:12:41 -0400 [thread overview]
Message-ID: <20070519161104.7C8161E8C1F@holo.morphisms.net> (raw)
In-Reply-To: <20070519063834.GC96831@kris.home>
> If we're to compare channels to any
> language feature, though, why not closures?
And why not for loops?
Prime sieves and power series are undeniably clean
message-passing programs. They are good examples
of *how* channels can be used, but not *why*
channels are useful in systems programs.
Channels provide a mechanism for implementing the
interface between two different pieces of code and
also a way to synchronize the two. Both are very
important reasons why people use channels for
systems programming. Closures alone don't provide
either.
Closures are useful too, just for different things.
Acme uses a trick where closures get sent from one
proc to another along a channel in order to start
the closure running as a new thread in the target
proc. The acme paper, p. 12 (Concurrency in the
implementation) discusses this.
When using libthread (or Alef), one reason you
care which proc each thread (task) runs in is that
when a proc blocks on a system call (not a channel
op), all the other threads in that proc block too.
So you might have one proc whose only job is to do
blocking I/O, using a channel to get I/O requests
from threads in other procs -- see ioproc(2) for a
library that wraps this up (ioproc(3) on p9p).
I reimplemented venti's buildindex a couple years
ago to run a lot faster. In the new buildindex,
the first step is to read each data block on the
arena disks, make an index entry for that data
block, and write it to the correct index disk, in
any order. (Future passes sort the individual
index disks into the right format, in parallel.
This step is just "spraying" each index entry onto
the right disk, like a multiway quicksort pivot.)
Buildindex starts a proc reading each arena and a
proc writing each index disk. The arena procs
just read a data block at a time and write an
index entry to the channel for the appropriate
disk. Each index proc reads a buffer worth of
index entries from its disk's channel, writes the
buffer to disk, and repeats. It just worked the
first time, and channels made the I/O trivial.
Russ
next prev parent reply other threads:[~2007-05-19 16:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 23:45 Uriel
2007-05-19 3:24 ` Micah Stetson
2007-05-19 4:03 ` Rob Pike
2007-05-19 4:12 ` erik quanstrom
2007-05-19 4:36 ` W B Hacker
2007-05-19 4:55 ` Rob Pike
2007-05-19 5:13 ` W B Hacker
2007-05-19 6:38 ` Kris Maglione
2007-05-19 16:12 ` Russ Cox [this message]
2007-05-22 18:32 ` David Leimbach
2007-05-22 22:07 ` W B Hacker
2007-05-22 23:34 ` Bakul Shah
2007-05-23 13:32 ` David Leimbach
2007-06-01 4:59 ` Jeff Sickel
2007-06-01 11:28 ` David Leimbach
2007-06-01 13:48 ` Russ Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070519161104.7C8161E8C1F@holo.morphisms.net \
--to=rsc@swtch.com \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).