Date: Fri, 10 Dec 1999 14:04:06 -0700 From: Nate Williams <nate@mt.sri.com> To: Chuck Robey <chuckr@picnic.mat.net> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, freebsd-arch@freebsd.org Subject: Re: Thread scheduling Message-ID: <199912102104.OAA21584@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9912100026210.16082-100000@picnic.mat.net> References: <99Dec10.155600est.40337@border.alcanet.com.au> <Pine.BSF.4.10.9912100026210.16082-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >That is, is it important at all that all processors be doing the same > > >multithreading task (if it's multithreaded, and wants it) at exactly the > > >same time? > > > > I don't think this is guaranteed anywhere. In any case, IMHO it would > > be virtually impossible for a system to provide such a guarantee - > > consider a system which provided such a guarantee and currently has > > two threads executing on two CPUs. An interrupt then occurs on one > > CPU - what happens to the thread on the other CPU (which hasn't seen > > the interrupt)? What happens if (as a result of the interrupt) a > > higher priority process becomes runnable? > > I can think of several ways for it to be done, so lets concentrate on > whether it's needed or desireable. No and no. If any software relies on it, it's completely broken for Uniprocessor machines, since they can't make any such guarantees. Having multiple threads occuring simultaneous is an effeciency issue, but should never be relied on for correct operation of the algorithms in a general purpose computing platform. Nate 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?199912102104.OAA21584>