From owner-freebsd-bugs Sat Oct 24 05:00:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA07232 for freebsd-bugs-outgoing; Sat, 24 Oct 1998 05:00:06 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA07219 for ; Sat, 24 Oct 1998 05:00:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id FAA23691; Sat, 24 Oct 1998 05:00:01 -0700 (PDT) Date: Sat, 24 Oct 1998 05:00:01 -0700 (PDT) Message-Id: <199810241200.FAA23691@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Dmitrij Tejblum Subject: Re: kern/8375: pthread_cond_wait() spins the CPU Reply-To: Dmitrij Tejblum Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8375; it has been noted by GNATS. From: Dmitrij Tejblum To: John Birrell 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