From owner-freebsd-arch Thu Dec 27 6:49:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 78E5637B41A for ; Thu, 27 Dec 2001 06:49:34 -0800 (PST) Received: from vigrid.com (pm3-pt23.pcnet.net [206.105.29.97]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id fBREmNVm019359; Thu, 27 Dec 2001 09:48:27 -0500 (EST) Message-ID: <3C2B36EB.77BE2A1F@vigrid.com> Date: Thu, 27 Dec 2001 09:57:47 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: the condvar stuff. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Thu, 27 Dec 2001, Alfred Perlstein wrote: > > > * Julian Elischer [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