Date: Thu, 27 Mar 2003 02:17:25 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: David Xu <davidxu@freebsd.org> Cc: arch@freebsd.org Subject: Re: 1:1 threading. Message-ID: <20030327020402.T64602-100000@mail.chesapeake.net> In-Reply-To: <006a01c2f3ff$e57cb300$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Mar 2003, David Xu wrote: > After reading your 1:1 threading code, I think you needn't > hack current KSE code to build your own 1:1 threading code. > Our code allow you to do this, actully, it's my earlier > idea to let 1:1 be implemented in our M:N code base, but never > had told this to julian or others. It was actually done outside of KSE on purpose. It keeps the API simpler and cleaner. It keeps the implementation cleaner. It keeps it out of the majority of the KSE code paths aside from thread_suspend and related code. I wanted something small and stable that built on top of KSE provided primitives but did not actually use the KSE apis. This makes it easier for KSE to continue growing and changing while the 1:1 code remains simple. It also removes some of the cost associated with doing KSE. > if you want to create a thread, you can always call kse_create > syscall(the name should be changed to another, for example > upcall_create), the newly created upcall will be scheduled a > kernel thread on it and return to userland thread stack and > thread function, if you want to implement 1:1, you can always > set kse_mailbox.km_curthread to NULL, this ensures that userland > stack always has fixed association with kernel thread stack, > for me, 1:1 only means userland stack has fixed association with > kernel thread stack, no more. however, code in kse_create should be > adjusted to allow NUPCALLS > NCPUS, this allows 1:1 mode to be > implemented. thr_exit can be implemented to use kse_exit, and maybe > a wrapper to for kse_exit. > For thr_kill, I think we may add an API to allow a kernel > thread be identified by using kse_mailbox pointer or something > similar. I intend to keep thr_kill as is since it is the most simple and direct way to acomplish the POSIX semantics. > By implementing 1:1 code in current M:N code base, benifit is very > clear, a ksegrp protects time quantum and threads priority, and if > you want to implement a system scope thread(I know pthread has this > requirement), just call kse_create with newgroup parameters is 1, > you will immediately get a system scope thread. I have considered using the ksegrp for this purpose but I view that as an advanced feature not required to get threading off the ground. I'm trying to take reasonable steps that provide functionality all along the way. > Yes, you may think that KSE progress is slow, but I'd like to think KSE progress has been far too slow. Many people are migrating away from freebsd for other platforms due to our lack of threading. This project has been underway for a significant amount of time. I did the 1:1 threading because I view this as the most reasonable way to get good threading in a short period of time. > harder before pushing some not well thinked code into kernel. It is quite well thought out. Given the track record of the KSE project I actually take some offense to the suggestion that my code is not well thought out in comparison. > At least, when I am thinking about M:N, I am also thinking about > 1:1, I guess some people like 1:1, and others like M:N, so more choise is good. > > David Xu Yes, I think they both have their place. I think we can support both in the tree as well. Hopefully the 1:1 code will address most users needs until M:N is production ready. Cheers, Jeff > ----- Original Message ----- > From: "Jeff Roberson" <jroberson@chesapeake.net> > To: <kse@elischer.org> > Sent: Wednesday, March 26, 2003 11:00 AM > Subject: 1:1 threading. > > > > I just sent a mail to arch@ about a parallel effort that you all may be > > interested in. Please follow up there. > > > > Thanks, > > Jeff >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030327020402.T64602-100000>