Date: Thu, 27 Dec 2001 04:01:46 -0600 From: Alfred Perlstein <bright@mu.org> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: the condvar stuff. Message-ID: <20011227040146.A55891@elvis.mu.org> In-Reply-To: <Pine.BSF.4.21.0112270045200.85465-100000@InterJet.elischer.org>; from julian@elischer.org on Thu, Dec 27, 2001 at 01:18:08AM -0800 References: <20011227001401.Y91594@elvis.mu.org> <Pine.BSF.4.21.0112270045200.85465-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Julian Elischer <julian@elischer.org> [011227 03:20] wrote: > > > On Thu, 27 Dec 2001, Alfred Perlstein wrote: > > > * Julian Elischer <julian@elischer.org> [011227 00:00] wrote: > > > > > > Ok, so, I[ve looked at the code, > > > I've read teh man pages. > > > I've looked at soem usages.. > > > > > > > > > Why do we need the condvar stuff? it seems very similar > > > to the existing msleep code. > > > > They're a lot easier to get right than the flags based approach > > since you don't have to roll your own. > > In other words they are like msleep. Yes. > > They also specify a specific rendivous so that at a later date we > > won't need the sched_lock to place processes on the condvar's waiting > > queue. > > You'll still need to hold schedlock to take the running thread > out of the running state and select the next to run so I don't see > a great advantage to that. > > > You use the mutex passed in as the protection over the > > condvar, this is possible because if you think about it, it makes > > no sense to use more than one mutex with either a condvar or a > > set of flags, right? :) > > I see a weakness in that there is a cv_wait() with no cancelability. I > need to be able to cancel any cv or msleep in a threads world... Well I > don't NEED to but if I can't cancel a thread waiting on a cv then exit() > can take arbitrarily long as the exiting thread has to wait for all the > other threads to finish waiting on the CV. This is too much work. What you want to do is post signals to each "thread", this will make all interruptable (PCATCH/cv_sig) threads return up the syscall path. You may have to wait for non PCATCH/cv_sig threads because you have no choice. Most of those uninterruptable sleeps are there because it would be really difficult to handle an abort at that stage or becuase you've loaned out a resource that you must reclaim in order to "set right". For now you should just consider using the existing mechanisms, something like a posted signal and not worry about the uninterruptable sleeps. > Basically one of the changes I'll be doing in the KSE tree > as that all msleeps and cv waits and sx waits and mutx waits have > to either be identifiable as uninterruptable, or ba capable of > being interrupted (so at least the next layer can catch it and back out). Yes, this is what PCATCH is for. -- -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?20011227040146.A55891>