Date: Fri, 12 Nov 1999 09:21:11 +0100 From: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com> To: Daniel Eischen <eischen@vigrid.com> Cc: "freebsd-arch@FreeBSD.ORG" <freebsd-arch@freebsd.org> Subject: Re: Threads goals and implementation Message-ID: <382BCDF7.8689BA4B@germany.sun.com> References: <Pine.SUN.3.91.991111122739.24392A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Thu, 11 Nov 1999, Michael Schuster - TSC SunOS Germany wrote: [...] > > > 9/ There exists a set of primatives that allow threads to influence the > > > in-process scheduling between themselves. > > > 9A/ e.g. 'per thread' Thread scheduling classes. > > > > scheduling class is an attribute of a thread, therefore a resource -> > > ergo contradiction to 5/ & 6/ > > This doesn't have to imply scheduling across all threads in the system. > It does state "in-process" scheduling, so I don't think that 9A is > meant to include system scheduling classes. I actually didn't mean to say so, so yes, I agree with you here (am I contradicting myself? I don't really think so :-) > > my suggestion: > > > > 5/ All threads in a process share the same resources by default with > > the following possible exceptions > > 5a/ the (limits for) the following resources can be set on a > > per-thread basis: priority, quantum, scheduling class.. (your favourite > > here) > > 5b/ thread-specific data such as curthread, thread stack, etc. > > > > and do away with 6/, 9/, 10/ and 13/ > > Makes sense to me, though I think that "quick access to TSD and current > thread" is a goal. I meant to say that, I must have lost it somewhere. :-) > Dan Eischen > eischen@vigrid.com cheerio Michael -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?382BCDF7.8689BA4B>