[9fans] Channels and threads - Plan9

This is a discussion on [9fans] Channels and threads - Plan9 ; -----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/iyWX0NBMJYAcRAiMjAJ0fBysIkAI3EMpTbvkA2hjRRsQPtwCgr 6/l 0ByAl98Rk56SCBpTyDRn47M= =cBqL -----END PGP SIGNATURE-----...

+ Reply to Thread
Results 1 to 11 of 11

Thread: [9fans] Channels and threads

  1. [9fans] Channels and threads

    -----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/iyWX0NBMJYAcRAiMjAJ0fBysIkAI3EMpTbvkA2hjRRsQPtwCgr 6/l
    0ByAl98Rk56SCBpTyDRn47M=
    =cBqL
    -----END PGP SIGNATURE-----

  2. Re: [9fans] Channels and threads

    > 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


  3. Re: [9fans] Channels and threads

    -----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+N XNUlBXBACdGaxj
    kKd8TljZ7kXHc8vB/qKEHIg=
    =Sec4
    -----END PGP SIGNATURE-----

  4. Re: [9fans] Channels and threads

    > 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


  5. Re: [9fans] Channels and threads

    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

  6. Re: [9fans] Channels and threads

    > 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"

  7. Re: [9fans] Channels and threads

    -----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-----

  8. Re: [9fans] Channels and threads

    -----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-----

  9. Re: [9fans] Channels and threads

    On 11/7/07, erik quanstrom wrote:

    // wiring data to processors would make more sense.

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

  10. Re: [9fans] Channels and threads

    > On 11/7/07, erik quanstrom 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


  11. Re: [9fans] Channels and threads

    On Nov 8, 2007 7:35 AM, don bailey 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?do...32012617965344

    HTH

+ Reply to Thread