From owner-freebsd-current Mon Jul 23 11: 3:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 7B2C837B401 for ; Mon, 23 Jul 2001 11:03:38 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.4/8.11.2) with ESMTP id f6NI2qv99392; Mon, 23 Jul 2001 11:02:52 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3B5BD998.3E8A6E7E@elischer.org> Date: Mon, 23 Jul 2001 11:02:57 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: RE: mutex blocking queues.. Cc: current@FreeBSD.org 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 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