Date: Thu, 27 Dec 2001 09:57:47 -0500 From: Dan Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: the condvar stuff. Message-ID: <3C2B36EB.77BE2A1F@vigrid.com> References: <Pine.BSF.4.21.0112270045200.85465-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer 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. I think msleep should go bye-bye. Instances of it should be converted to mutex/cv pairs. > > > > 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. Isn't there cv_wait_sig/cv_timedwait_sig? I don't think you should be able to cancel (interrupt) threads that are waiting on mutexes or cv's that are not in cv_wait_sig/cv_timedwait_sig. Mutexes should be used for only very short periods of time. Calling code should use cv_wait_sig and cv_timedwait_sig if at all possible and handle the interruption when it occurs. > The problem is that there is no return value, so you can not tell the > calling code that it's thread has just been shot in the head. There are return values for cv_[timed]wait_sig. > I have two new functions in the KSE tree abortsleep(td) and cv_abort(td), > that rip the given thread out of whatever it's doing when the process > exits. but it's not possible to tell if a particular CV was done using > cv_wait() or cv_wait_sig() or whatever, so I don't really know if it's > safe to wake it. > > I just wake it and let whatever it was that went to sleep > (e.g. cv_wait_sig()) discover the "I'm Exititng" flag for itself.) > > 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). Convert msleeps to mutex/cv pairs, and cv_[timed]wait to cv_[timed]wait_sig. If the calling code can be made to handle an interruption, then it should be using *_sig variants anyways. There might be places that can't handle it though... -- 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?3C2B36EB.77BE2A1F>