Date: Tue, 19 Jan 2010 10:38:58 +0900 (JST) From: Kohji Okuno <okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org Cc: okuno.kohji@jp.panasonic.com, freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? Message-ID: <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> In-Reply-To: <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Attilio,
I think setpriority() can set priority to sleeping threads.
Is it really safe?
Thank you,
Kohji Okuno
> 2010/1/18 Kohji Okuno <okuno.kohji@jp.panasonic.com>:
>> 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.
>>
>> <<Back Trace>>
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100119.103858.29593248145858473.okuno.kohji>