From owner-freebsd-arch Thu Dec 27 1:20:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id EEDF237B417 for ; Thu, 27 Dec 2001 01:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227092009.BDY20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 09:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA86370; Thu, 27 Dec 2001 01:18:09 -0800 (PST) Date: Thu, 27 Dec 2001 01:18:08 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: the condvar stuff. In-Reply-To: <20011227001401.Y91594@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. > > 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. 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. 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). because when one thread runs 'exit()' it waits around for all the other threads to exit before proceeding. This also applies to exec() except that I haven't written that yet. Julian (diffs available from my web page on freefall) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message