From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 01:39:12 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 794F41065670; Tue, 19 Jan 2010 01:39:12 +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 0993C8FC12; Tue, 19 Jan 2010 01:39:11 +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-maile13) with ESMTP id o0J1dAja018445; Tue, 19 Jan 2010 10:39:10 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id o0J1d9S26194; Tue, 19 Jan 2010 10:39:09 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla1) id o0J1dAm1026843; Tue, 19 Jan 2010 10:39:10 +0900 (JST) Received: from localhost by somla1.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0J1d3MD026582; Tue, 19 Jan 2010 10:39:03 +0900 (JST) Date: Tue, 19 Jan 2010 10:38:58 +0900 (JST) Message-Id: <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org From: Kohji Okuno In-Reply-To: <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@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: Tue, 19 Jan 2010 01:39:12 -0000 Hello, Attilio, I think setpriority() can set priority to sleeping threads. Is it really safe? Thank you, Kohji Okuno > 2010/1/18 Kohji Okuno : >> Hello, >> >> Thank you, Attilio. >> I checked your patch. I think that your patch is better. >> I tested the patch quickly, and I think it's OK. >> # This probrem does not occur easily :-< >> >> >> What do you think about maybe_resched()? >> I have never experienced about maybe_resched(), but I think that the= >> race condition may occur. >> >> <> >> sched_4bsd.c: =A0 =A0 maybe_resched() >> sched_4bsd.c: =A0 =A0 resetpriority_thread() >> sched_4bsd.c: =A0 =A0 sched_nice() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= get thread_lock(td) >> kern_resource.c: =A0donice() >> kern_resource.c: =A0setpriority() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ge= t PROC_LOCK() >> >> static void >> maybe_resched(struct thread *td) >> { >> =A0 =A0 =A0 =A0THREAD_LOCK_ASSERT(td, MA_OWNED); >> =A0 =A0 =A0 =A0if (td->td_priority < curthread->td_priority) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curthread->td_flags |=3D TDF_NEEDRESC= HED; >> } >> >> I think, when td->td_lock is not &sched_lock, curthread->td_lock is >> not locked in maybe_resched(). > = > I didn't look closely to the maybe_resched() callers but I think it i= s > ok. The thread_lock() function works in a way that the callers don't > need to know which container lock is present in a particular moment, > there is always a guarantee that the contenders will spin if the lock= > on the struct can't be held. > In the case you outlined something very particular was happening. > Basically, we get &sched_lock but sched_lock was not the lock present= > on td_lock. That means all the other paths willing to access to > td_lock for that thread (via thread_lock()) were allowed to do that > even if we wanted to keep the critical path closed. > = > Attilio > = > = > -- = > Peace can only be achieved by understanding - A. Einstein