[9fans] Channels and threads

[9fans] Channels and threads

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, what's the rationale behind using Channels?
Is passing by reference not recommended by Plan 9 design?

D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHMi/iyWX0NBMJYAcRAiMjAJ0fBysIkAI3EMpTbvkA2hjRRsQPtwCgr6/l
0ByAl98Rk56SCBpTyDRn47M=
=cBqL
-----END PGP SIGNATURE-----

Re: [9fans] Channels and threads

[erik quanstrom]

> So, what's the rationale behind using Channels?
> Is passing by reference not recommended by Plan 9 design?
> 
> D

channels (the libthread variety) may pass by reference or value.
so passing by reference or value is orthagonal to the question
of why channels.

for example, if you have a couple of i/o threads and one mux,
the mux can wait for a message from one of the i/o threads
that might say
a) here's your data (8192 byte+overhead message), or
b) your data is here (sizeof pointer+overhead message)

- erik

Re: [9fans] Channels and threads

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> channels (the libthread variety) may pass by reference or value.
> so passing by reference or value is orthagonal to the question
> of why channels.
> 
> for example, if you have a couple of i/o threads and one mux,
> the mux can wait for a message from one of the i/o threads
> that might say
> a) here's your data (8192 byte+overhead message), or
> b) your data is here (sizeof pointer+overhead message)
> 

Well, yeah, I get that. I think the question I need to
ask is "why use Channels at all?"

What is the benefit of using Channels when threads can't
be bound to a specific CPU in a multi-core system? Aren't
Channels just a wrapper for locking a mutex and setting
a variable or adding to a queue?

D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHMjXuyWX0NBMJYAcRAhDLAJ9l4vEwsLOBPUorybgd+NXNUlBXBACdGaxj
kKd8TljZ7kXHc8vB/qKEHIg=
=Sec4
-----END PGP SIGNATURE-----

Re: [9fans] Channels and threads

[erik quanstrom]

> Well, yeah, I get that. I think the question I need to
> ask is "why use Channels at all?"
> 
> What is the benefit of using Channels when threads can't
> be bound to a specific CPU in a multi-core system? Aren't
> Channels just a wrapper for locking a mutex and setting
> a variable or adding to a queue?

procs, not threads, can be "wired" to specific
processors.  so if your interest is to wire tasks (for lack of a
better term) to processors, you can do that with procs.

on modern pc hardware, the gulf between memory and
the processor is large enough, that i'm not sure that you'd
want to wire procs to processors.  wiring data to processors
would make more sense.

- erik

Re: [9fans] Channels and threads

[ron minnich]

Where are the slides for Sape's excellent talk on the jukebox? Between
that and Rob's talk at Google the channels discussion might be more
understandable.

Thanks

ron

Re: [9fans] Channels and threads

[david jeannot]

> Well, yeah, I get that. I think the question I need to
> ask is "why use Channels at all?"

"It's remarkably easy to write software this way."
quoted from rob pike in "Rio: Design of a Concurrent Window"

Re: [9fans] Channels and threads

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ron minnich wrote:
> Where are the slides for Sape's excellent talk on the jukebox? Between
> that and Rob's talk at Google the channels discussion might be more
> understandable.
> 

Hook me up.

D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHMj2uyWX0NBMJYAcRAjX7AJ4xvlzGgqPxSuoDNH12ZI+3fln4DwCfapF1
FAGdPHpcoZvjPlGO1odib10=
=k6/f
-----END PGP SIGNATURE-----

Re: [9fans] Channels and threads

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> on modern pc hardware, the gulf between memory and
> the processor is large enough, that i'm not sure that you'd
> want to wire procs to processors.  wiring data to processors
> would make more sense.
> 

Eh...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHMj80yWX0NBMJYAcRAggWAKCNOdNUCHIlon/Q58FM7Po64yZFOACdFoA+
UB2yopR4HUqgEGK/c1cDvto=
=goOg
-----END PGP SIGNATURE-----

Re: [9fans] Channels and threads

[Anthony Sorace]

On 11/7/07, erik quanstrom <quanstro@quanstro.net> wrote:

// wiring data to processors would make more sense.

is what's meant here "wiring (data+proc) to processors would make more sense"?

Re: [9fans] Channels and threads

[erik quanstrom]

> On 11/7/07, erik quanstrom <quanstro@quanstro.net> wrote:
> 
> // wiring data to processors would make more sense.
> 
> is what's meant here "wiring (data+proc) to processors would make more sense"?

no, if you're using threads (procs), by definition mutiple actors are
chewing on the same data.  if performance matters enough to worry
about which processor does what, i would think your data set would be
large enough to be much bigger than the active code.  therefore, i
would worry about keeping the data set wired to a processor and not
worry about which procs are running where.

- erik

Re: [9fans] Channels and threads

[Navin Johnson]

On Nov 8, 2007 7:35 AM, don bailey <don.bailey@gmail.com> wrote:
> ron minnich wrote:
> > Where are the slides for Sape's excellent talk on the jukebox? Between
> > that and Rob's talk at Google the channels discussion might be more
> > understandable.
> >
>
> Hook me up.

Managing Concurrency in Distributed Systems
http://plan9.bell-labs.com/who/sape/gos/slides-day1.ps

Advanced Topics in Programming Languages: Concurrency/message passing Newsqueak
http://video.google.com/videoplay?docid=810232012617965344

HTH