Date: Sat, 24 Oct 1998 05:00:01 -0700 (PDT) From: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8375: pthread_cond_wait() spins the CPU Message-ID: <199810241200.FAA23691@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: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
To: John Birrell <jb@cimlogic.com.au>
Cc: eischen@vigrid.com (Daniel Eischen), freebsd-gnats-submit@FreeBSD.ORG,
jb@FreeBSD.ORG
Subject: Re: kern/8375: pthread_cond_wait() spins the CPU
Date: Sat, 24 Oct 1998 15:49:22 +0400
John Birrell wrote:
> 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
^^^^^ spinlock?
> 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).
IMO, is this _SPINUNLOCK is too early or changing the thread state is too late
is not that important :-). Anyway, I would suggest to add 'spinlock_t *'
parameter to _thread_kern_sched_state. _thread_kern_sched_state would set
the state, unlock the spinlock and enter the scheduler. This would be useful
in quite a lot of places. (Richard Seaman sent a patch with a similar idea, but
I don't like something in it).
Dima
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?199810241200.FAA23691>