From owner-freebsd-current Wed Nov 4 23:55:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA00885 for freebsd-current-outgoing; Wed, 4 Nov 1998 23:55:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA00870 for ; Wed, 4 Nov 1998 23:55:10 -0800 (PST) (envelope-from will@ns.oeno.com) Received: (qmail 24773 invoked by uid 1001); 5 Nov 1998 07:55:01 -0000 To: Julian Elischer Cc: current@FreeBSD.ORG Subject: Re: Kernel threading (was Re: Thread Scheduler bug) References: From: Ville-Pertti Keinonen Date: 05 Nov 1998 09:52:55 +0200 In-Reply-To: Julian Elischer's message of "4 Nov 1998 07:15:50 +0200" Message-ID: <864ssed19k.fsf@not.oeno.com> Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer writes: > easier to simply have a single pointer in a known address > that gets rewritten by the kernel on scheduling.. probably actually an > array of them, (one per cpu) with a 'getcpunumber()' to allow > the thread to work out which it should use. Do I understand you correctly that you're suggesting this for user-space code? Finding out which cpu you're running on in user mode isn't easier than finding out what thread you're running unless you mmap the local apic. Even then, how do you prevent the kernel from switching while you're holding the index? The i386 doesn't indirect deep enough in one insn. An m68k (from 68020 up) could do it. ;--) You know it can't switch threads because you wouldn't be executing in that context, but each instruction executed as the thread could be executed by a different cpu. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message