Date: Mon, 21 Dec 1998 09:29:09 -0800 From: Mike Smith <mike@smith.net.au> To: Chuck Robey <chuckr@mat.net> Cc: Mike Smith <mike@smith.net.au>, "Daniel C. Sobral" <dcs@newsguy.com>, current@FreeBSD.ORG Subject: Re: Pb with COMPAT_LINUX_THREADS Message-ID: <199812211729.JAA02261@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 21 Dec 1998 11:30:25 EST." <Pine.BSF.4.05.9812211118320.342-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I have been wondering about this... Multithreading is usually used to improve > > > performance. Wouldn't this "on-demand" allocation of shared signals impact of > > > performance? > > > > You typically thread for the concurrency win, and wear the startup cost > > as an overhead that you have to pay back with concurrency. Given that > > at the moment we're looking at a heavyweight thread implementation, > > this extra allocation is relatively trivial in the scheme of things. > > My semester is over, I'm only now starting to catch up on the > interesting stuff on threads ... for scheduling purposes, then, you want > to keep track of how many active threads a threaded process has, and > have the scheduler grab that many cpus when a context switch occurs? No. You want to schedule each individual thread as though it were a process in and of itself. > How is the time for the threaded process to be accounted? I see (for > purposes of scheduler priorities) that either total cputime given, > across all cpus, could be used, if you wanted to keep non-threaded apps > on an even parity with threaded apps. Alternatively, if you wanted to > give threaded apps a definite win, then you would only keep cpu stats, > perhaps, on a parent thread? In the current LinuxThreads support mode, threads are processes, so each thread's time is accounted against itself. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812211729.JAA02261>