Date: Tue, 22 Jan 2002 12:54:47 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@freebsd.org, dillon@freebsd.org Subject: Re: STOP and SLEEP in the kernel Message-ID: <Pine.BSF.4.21.0201221238360.18165-100000@InterJet.elischer.org> In-Reply-To: <20020122123406.D13686@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Jan 2002, Alfred Perlstein wrote: > * Julian Elischer <julian@elischer.org> [020122 12:00] wrote: > > > > Matt Dillon and I spent some time looking at the way in which process > > suspension is achieved in FreeBSD in order to try work out how best to do > > it in the KSE kernel. > > > > We discovered a couple of things. > > FIrstly that teh suspension occurs in CURSIG() which is an alias for > > issignal() > > To deal with these issues it may be a good idea to consider a rundown > state in which kses automatically exit right before returning to userland. > > This should help: This is what is being done (approximatley) However the rundown (exit) state is part of a new state called 'singlethreading' in which case only one thread is allowed to continue while all other threads are suspended or forced to exit, depending on how viscious the single-threader is feeling. For exit() it sets the 'exit' flag but in fork() and exec() it sets the flag to 'suspend'. it is notified when it is the only runnable thread left. userret() is modified to check this state before going back to userland and the threads either call thread_exit() or thread_suspend() depending on the wishes of the master thread. Singlethreading, in turn is part of a larger state called 'suspended' for which all threads must check at strategic locations and act accordingly. This will be set by psignal() in the case of a SIGSTOP and by the TRACE code and also by the singlethreading code. (The check makes the master thread immune to suspending if the singlethreading bit is the only bit set in the suspended flags.) The locations of the checks for suspension have also to take into account that they may need to handle the case of exit() pulling the pin, and causing whatever syscall they are in to abort completely. The safest place for the check is in userret(), but if we wish to fully simulate the current susoension code then we also need to add the checks to issignal() (CURSIG()), or more likely, right next to where CURSIG() is called, and change CURSIG() to not to do the check. SUSPENSION is not limited to signals so CURSIG is not really the right place, though it may be called from all teh right places :-) ALSO there is a whole different STOPPING mechanism in the kernel as well. I refer to the STOPEVENT() stuff, which actually uses msleep() to stop the thread. This needs to be rationalised. We should have only one stopping/suspending mechanism, not 3. > > thread A calls exit(2). > > in exit(2) the thread aquires a lock on the proc struct. > if the thread count is 1, it just exit(2)s, otherwise: > > it marks "in exit" in the proc struct. > it then signalls all threads with a non blockable signal. > (this will cause them to enter the kernel or interrupt any long blocking > operation.) > it then sleeps on the proc struct's thread count address or a cv. been looking at my code huh? :-) > > Now all other threads should be in the kernel. > They will post a signal to themselves to help them avoid blocking. > At exit points they will notice the flag and self terminate themselves, > they will decerement the thread count. > The second to last thread (the thread other than 'A') will notice the > count go to '1' and wakeup the exit(2)'ing thread. > > Done. yep that's what I'm doing... check out the posted diffs. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ > 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.21.0201221238360.18165-100000>