Date: Sat, 24 Oct 1998 06:10:01 -0700 (PDT) From: Daniel Eischen <eischen@vigrid.com> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8375: pthread_cond_wait() spins the CPU Message-ID: <199810241310.GAA25085@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/8375; it has been noted by GNATS.
From: Daniel Eischen <eischen@vigrid.com>
To: eischen@vigrid.com, jb@cimlogic.com.au
Cc: dima@tejblum.dnttm.rssi.ru, freebsd-gnats-submit@FreeBSD.ORG,
jb@FreeBSD.ORG
Subject: Re: kern/8375: pthread_cond_wait() spins the CPU
Date: Sat, 24 Oct 1998 08:52:45 -0400 (EDT)
> > If thread scheduling is kicked off right after the last
> > SPINUNLOCK, then you can also have a thread removed
> > from the mutex queue, but it'll never get woken up.
>
> The simple solution to this is to change the thread state to PS_MUTEX_WAIT
> while the mutex is locked, then enter the scheduler without changing the
> state. I don't think that the problem is one of locking - just the
> possibility that the thread state will be overwritten at an inoportune
> time (i.e. the thread state may be changed to PS_RUNNING before it
> gets a chance to set it's state to PS_MUTEX_WAIT).
That works. If you want to keep your __FILE__ and __LINE__
debug thingys, you'll have to add another interface for
_thread_kern_sched_state that doesn't change the state,
though.
Dan Eischen
eischen@vigrid.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810241310.GAA25085>