From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 08:05:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C4BF1065676; Fri, 22 Jan 2010 08:05:26 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id DB77F8FC0C; Fri, 22 Jan 2010 08:05:25 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id o0M85Njo001694; Fri, 22 Jan 2010 17:05:23 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id o0M85Mm15269; Fri, 22 Jan 2010 17:05:22 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla5) id o0M85KjN012449; Fri, 22 Jan 2010 17:05:20 +0900 (JST) Received: from localhost by somla5.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0M85FZc012172; Fri, 22 Jan 2010 17:05:15 +0900 (JST) Date: Fri, 22 Jan 2010 17:05:13 +0900 (JST) Message-Id: <20100122.170513.468378203492549701.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org From: Kohji Okuno In-Reply-To: <3bbf2fe11001211532i1cc4eaa8n3d56df04f337298@mail.gmail.com> References: <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> <20100120.115218.999284356098982813.okuno.kohji@jp.panasonic.com> <3bbf2fe11001211532i1cc4eaa8n3d56df04f337298@mail.gmail.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: okuno.kohji@jp.panasonic.com, freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 08:05:26 -0000 Hello, Attilio, >>>>> I think setpriority() can set priority to sleeping threads. >>>>> Is it really safe? >>>> >>>> I agree, in this code path maybe_resched is not properly locking c= urthread. >>>> =A0curthread will be sched_lock and the sleeping thread will be a = sleepq lock. >>>> =A0I believe that since &sched_lock is ordered after container loc= ks it would >>>> be sufficient to compare the two td_lock pointers and acquire sche= d_lock if >>>> they are not equal. =A0Someone should look at other maybe_resched = callers or >>>> add an assert that curthread->td_lock is always &sched_lock in thi= s >>>> function. >>> >>> I'm not sure I understand you well here, but I generally don't agre= e, >>> if we speak about the current code plus the patch I posted. >> >> I understood. If the current code plus your patch, meybe_resched() i= s >> no problem. I think, your patch is perfect if theare is no problem >> even if a sleeping thread sets &sched_lock to td->td_lock. >> >> Why do we call thread_lock_set() in sleepq_switch() and turnstile_wa= it()? >> In case of sched_4bsd, is not thread_lock_set() needed? > = > This question may be needing a very long answer :) > = > The short one, though, is that the thread_*lock*() interface handle > the locking of the thread containers (runqueues, sleepqueues, > turnstiles) transparently and in atomic way. > What happens is that threads may be (mostly, with some notable > exceptions like the ithread case being parked on IWAIT and not having= > a specific container) in one of the three above mentioned containers > which also need to handle flags and option specific to the thread and= > the container. In order to do that atomically you may need 'global' > locks that protects such interactions (thus you have sched_lock which= > protects runqueue, sleepqueue locks and turnstile locks). You could > also have just a global spinlock, but that would mean having a lot of= > intollerable contention on it. > thread_lock_set() is just used to switch locks when threads passes > from a container to another. > For example, immagine a thread running that goes blocking on a > turnstile. At some point, the thread container lock, as the thread > switches from runqueue to turnstile, needs to switch from sched_lock > to ts_lock and it is precisely when thread_lock_set() takes place. > Thus when the thread is resumed for running, it needs to switch again= > from ts_lock to sched_lock. > = > Attilio Thank you very much your detailed expositoin. I can understand. I'm looking forward to the good result of your new patch. Thank you, Kohji Okuno.