Date: Sun, 28 Nov 1999 16:30:35 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Threads stuff Message-ID: <Pine.BSF.4.10.9911281626180.544-100000@current1.whistle.com> In-Reply-To: <99Nov29.111117est.40352@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
I think there is confusion here.. The way Dan and I have been discussing it (you need to go back and read the old mail) the process creates several thread classes. Thread classes can be bound to a CPU and can have different system priorities. They are implemted in FreeBSD by rfork()ing a new process (called a subprocess. The scheduler then assigns threads to the subprocess. Effectively assigning them to a class. if the class is "all threads herein run on CPU1" tehn you get what you want.. Dan left of the "sub". Julian On Mon, 29 Nov 1999, Peter Jeremy wrote: > On 1999-Nov-29 05:54:55 +1100, Daniel M. Eischen wrote: > >Do we really want to be able to bind a _thread_ to a CPU? > > Yes. > > > Wouldn't it be sufficient to be able to bind a process to a CPU? > > Not really. If a process has multiple threads, it makes sense to be > able to specify CPU affinity for each thread, since each thread can > be scheduled independently. > > If you've got a multi-threaded process, I'm not sure why you'd want to > bind it as a whole to a single CPU. This implies that only one thread > can ever execute at once - which removes one major use for threads. > > Peter > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > 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?Pine.BSF.4.10.9911281626180.544-100000>