Date: Mon, 30 Jul 2001 16:18:45 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. Message-ID: <Pine.SUN.3.91.1010730160606.18329A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0107301253150.30207-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Jul 2001, Julian Elischer wrote: > Well, I'm quite a way into doing the KSE kernel. > > I have changed most of the interfaces to pass > threads around instead of procs and have the compile > going almost all teh way through everything upto teh end of 'kern' > working with anly a few minor errors. > > however there sre some things that need to be discussed... > these include: > > behaviour of a multithreaded program when stopped by the debugger, > and what happens when the user type ^Z on a multithreaded program. > > What iti comes down to is if a particular process is running on several > processors, and the user hits ^Z, how do I stop the threads that > are running on the other > processors? > > My guess is that I send some sort of Inter-processor Interrupt, after > having marked the process as stopped, and that on teh return > from the interrupt, the kernel on teh other processor should > notice this fact and deschedule its thread and run something else. > > I have also some really difficult times in trying to work out how to > tranlate such things as teh calls to put a process on teh run queue.. > > here's what I have at the moment for a first cut: > (For this example assume a 2 processor system) > > initial state: nothing on run queues, several threads on sleep queues. > Two KSEs have been created in one KSE group. > > Thread 1 becomes runnable.. we find the last KSE it ran on, > and as it is not runnable, we make THAT runnable, and put it on the run > queue. We hang the runnable thread off the KSE. (note at this stage there > is only one run queue). > > A processor picks the highest priority KSE and takes it off the run queue > and starts processing the first thread hung off it. > > Thread 2 comes ready. It also was last run on KSE-1 so it is hung off > the already running KSE-1. However since the number of runnable threads > is greater than the number of runnable KSEs, but less than the > number of KSEs created (2) we get another KSE at random (KSE-2) > and place it on the run queue. From the UTS perspective, it may be easier to deal with unblocking of threads if notifications were only on the KSE in which the thread was running. For concurrency levels > 1 (more than 1 KSE in the KSE Group), the UTS may have 2 sets of queues -- one for each concurrency level. If KSEs may get notifications for threads running in other KSEs, it means that there will have to be some inter-KSE locking of blocked and running thread queues. And each KSE has it's own mailbox, so it might force KSEs to fiddle with mailboxes they don't own. I'm not saying we can't do it, just that we may want to postpone that for later. -- Dan Eischen 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.SUN.3.91.1010730160606.18329A-100000>