From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60807310732w7afd01dah7d2c34a58a2c7965@mail.gmail.com> Date: Thu, 31 Jul 2008 07:32:45 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <5E49FED1C7E04F8A93BBACCF43D38EAD@T3400> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_89805_22959119.1217514766033" References: <488B6EE7.3080100@mtu.edu> <3e1162e60807301636h53149a9du80385a3e42a1a01a@mail.gmail.com> <13426df10807301702i38369688o8633274c9e94dcc5@mail.gmail.com> <3e1162e60807301848n7e2f0f52m5424707ddd02f746@mail.gmail.com> <13426df10807301923n95c9e0al1ebb12df795cc101@mail.gmail.com> <3e1162e60807310635s564a250eq3a492e6706592404@mail.gmail.com> <5E49FED1C7E04F8A93BBACCF43D38EAD@T3400> Subject: Re: [9fans] Plan 9 on Blue Gene Topicbox-Message-UUID: f85dedee-ead3-11e9-9d60-3106f5b1d025 ------=_Part_89805_22959119.1217514766033 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Jul 31, 2008 at 7:11 AM, Philippe Anel wrote: > That's almost what they do with KSE in FreeBSD (or Scheduler Activation > in NetBSD) right ? > > Phil; > KSEs were a way to make things that were not processes or threads in particular cooperatively scheduled with user-space callbacks. Basically the kernel signaled user-space to make a decision on what the next context would be. This is not the same a cooperatively scheduled coroutines where the re-scheduling happens as the result of making certain library calls to certain I/O routines (libtask does this, thanks again Russ!) KSEs were a mechanism to implement true-pre-emptive M:N threading for Posix threads... allowing M pthreads to be scheduled on N user processes. (I may have my M's and N's backwards). Usually what I've been seeing is the more popular thread implementations are 1:1, where each pthread is a user process as well. I'm not sure if KSE based threads or M:N in general, are a win in every situation people had hoped (or any for that matter). But then again I've not looked terribly deeply at this. 1:1 seems easier to reason about and keep track of :-) Dave > > > > > I've been writing a lot of Erlang code lately, and I keep thinking about, > but not having too much time to do much about, wanting to have a runtime for > the libthread "threads" that could auto-schedule them to libthread "procs", > in much the same way Haskell "sparks" may end up real threads, or Erlang > processes, might run in parallel. > > Dave > > >> >> >> ----- Original Message ----- From: "ron minnich" >> To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> >> Sent: Thursday, July 31, 2008 4:23 AM >> Subject: Re: [9fans] Plan 9 on Blue Gene >> >> >> >> On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach >>> wrote: >>> >>> Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be >>>> worth a ton to me in some situations. >>>> Concurrent programming for the win? >>>> >>> >>> probably not for this community. When we had plan9port in xcpu we got >>> nothing but complaints. This in spite of the fact that some things are >>> impossible to scale with 5000 posix threads, and easy to scale with >>> 5000 plan 9 style threads. >>> >>> ron >>> >>> >>> >> >> > ------=_Part_89805_22959119.1217514766033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Thu, Jul 31, 2008 at 7:11 AM, Philippe Anel <xigh@bouyapop.org> wrote:
That's almost what they do with KSE in FreeBSD (or Scheduler Activation in NetBSD) right ?
 
Phil;

KSEs were a way to make things that were not processes or threads in particular cooperatively scheduled with user-space callbacks.  Basically the kernel signaled user-space to make a decision on what the next context would be.  This is not the same a cooperatively scheduled coroutines where the re-scheduling happens as the result of making certain library calls to certain I/O routines  (libtask does this, thanks again Russ!)

KSEs were a mechanism to implement true-pre-emptive M:N threading for Posix threads... allowing M pthreads to be scheduled on N user processes. (I may have my M's and N's backwards).  

Usually what I've been seeing is the more popular thread implementations are 1:1, where each pthread is a user process as well.   I'm not sure if KSE based threads or M:N in general, are a win in every situation people had hoped (or any for that matter).  But then again I've not looked terribly deeply at this.  1:1 seems easier to reason about and keep track of :-)

Dave
 
 

 
I've been writing a lot of Erlang code lately, and I keep thinking about, but not having too much time to do much about, wanting to have a runtime for the libthread "threads" that could auto-schedule them to libthread "procs", in much the same way Haskell "sparks" may end up real threads, or Erlang processes, might run in parallel.

Dave
 


----- Original Message ----- From: "ron minnich" <rminnich@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Sent: Thursday, July 31, 2008 4:23 AM
Subject: Re: [9fans] Plan 9 on Blue Gene



On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach <leimy2k@gmail.com> wrote:

Does Plan 9 Port help?  I mean, libthread on Plan 9 Port alone could be
worth a ton to me in some situations.
Concurrent programming for the win?

probably not for this community. When we had plan9port in xcpu we got
nothing but complaints. This in spite of the fact that some things are
impossible to scale with 5000 posix threads, and easy to scale with
5000 plan 9 style threads.

ron






------=_Part_89805_22959119.1217514766033--