Date: Fri, 23 Oct 1998 22:00:01 -0700 (PDT) From: John Birrell <jb@cimlogic.com.au> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8375: pthread_cond_wait() spins the CPU Message-ID: <199810240500.WAA11830@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: John Birrell <jb@cimlogic.com.au>
To: eischen@vigrid.com (Daniel Eischen)
Cc: dima@tejblum.dnttm.rssi.ru, eischen@vigrid.com,
freebsd-gnats-submit@FreeBSD.ORG, jb@FreeBSD.ORG
Subject: Re: kern/8375: pthread_cond_wait() spins the CPU
Date: Sat, 24 Oct 1998 15:02:14 +1000 (EST)
Daniel Eischen wrote:
> BTW, pthread_mutex_lock also has the same problem as
> pthread_cond_wait if thread scheduling comes at an
> inopportune time:
[...]
> * Join the queue of threads waiting to lock
> * the mutex:
> */
> _thread_queue_enq(&(*mutex)->m_queue, _thread_run);
>
> /* Unlock the mutex structure: */
> _SPINUNLOCK(&(*mutex)->lock);
>
> /* Block signals: */
> _thread_kern_sched_state(PS_MUTEX_WAIT, __FILE__, __LINE__);
>
> 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).
--
John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
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?199810240500.WAA11830>