From owner-freebsd-current Tue Jul 24 16: 0:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 39EFD37B406; Tue, 24 Jul 2001 15:59:58 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA19555; Mon, 23 Jul 2001 15:26:14 -0700 (PDT) Date: Mon, 23 Jul 2001 15:26:12 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: current@FreeBSD.org Subject: RE: mutex blocking queues.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG this strikes me as avoidable. I'll think about it.. Until then I guess I'll just have two lists in the thread.. one for sleep and one for mutexes. On Mon, 23 Jul 2001, John Baldwin wrote: > > On 23-Jul-01 Julian Elischer wrote: > > Why does the mutex not link blocked processes though the > > sleep queue linked list entry? Why does it use the run queue entry? > > In KSEs the sleep queue and run queue enties go into different > > sub structures and ahve different types so this breaks... > > do I need to do something sleazy or can I just link them together using the > > equivalemt of the p_slpq entry? > > You can block on a mutex when processing signals in the catch case in msleep() > after you have put the process on the sleep queue: > > int > msleep(ident, mtx, priority, wmesg, timo) > { > ... > p->p_wchan = ident; > p->p_wmesg = wmesg; > p->p_slptime = 0; > p->p_pri.pri_level = priority & PRIMASK; > CTR5(KTR_PROC, "msleep: proc %p (pid %d, %s) on %s (%p)", p, p->p_pid, > p->p_comm, wmesg, ident); > TAILQ_INSERT_TAIL(&slpque[LOOKUP(ident)], p, p_slpq); > ... > /* > * We put ourselves on the sleep queue and start our timeout > * before calling CURSIG, as we could stop there, and a wakeup > * or a SIGCONT (or both) could occur while we were stopped. > * A SIGCONT would cause us to be marked as SSLEEP > * without resuming us, thus we must be ready for sleep > * when CURSIG is called. If the wakeup happens while we're > * stopped, p->p_wchan will be 0 upon return from CURSIG. > */ > if (catch) { > CTR3(KTR_PROC, "msleep caught: proc %p (pid %d, %s)", p, > p->p_pid, p->p_comm); > p->p_sflag |= PS_SINTR; > mtx_unlock_spin(&sched_lock); > PROC_LOCK(p); > sig = CURSIG(p); > mtx_lock_spin(&sched_lock); > PROC_UNLOCK_NOSWITCH(p); > ... > > If that proc_lock blocks then we don't want to clobber the sleep queue. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message