Date: Thu, 27 Dec 2001 01:18:08 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@freebsd.org Subject: Re: the condvar stuff. Message-ID: <Pine.BSF.4.21.0112270045200.85465-100000@InterJet.elischer.org> In-Reply-To: <20011227001401.Y91594@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0112270045200.85465-100000>