Date: Thu, 16 Oct 2003 12:45:26 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/sys mutex.h Message-ID: <XFMail.20031016124526.jhb@FreeBSD.org> In-Reply-To: <20031014225540.N30029-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15-Oct-2003 Jeff Roberson wrote:
> On Tue, 14 Oct 2003, John Baldwin wrote:
>> On 14-Oct-2003 Jeff Roberson wrote:
>> > I know it is racy in most contexts. I use it to check to see if a thread
>> > on the runq owns giant. Since I have the sched lock it isn't racy but
>> > even if it was it wouldn't matter in this case.
>>
>> sched lock doesn't keep it from being racy. Uncontested acquire and
>> releases don't go anywhere near sched lock. Are you checking a
>> non-curthread thread pointer? Maybe you could just do it for curthread
>> and that would be enough for your heuristic, i.e.
>
> Yes it does. I'm checking a thread that is on the run queue but not
> running. If it holds giant it will hold giant until I drop the sched lock
> and schedule it to run.
Ah, ok.
>>
>> if (thread == curthread && mtx_owned(&Giant)) {
>> ...
>> }
>>
>> I'm just worried that if this is there someone is going to use it. :(
>
> Yes, I see, this is a valid concern. I originally had it in sched_ule.c
> only but decided that it was ugly to do so. I could move it back or
> manually code the check there.
I would prefer that then. This is really only a "temporary" heuristic
while Giant exists anyways.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20031016124526.jhb>