From owner-freebsd-bugs Fri Oct 23 22:00:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA15200 for freebsd-bugs-outgoing; Fri, 23 Oct 1998 22:00:07 -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 WAA15188 for ; Fri, 23 Oct 1998 22:00:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id WAA11830; Fri, 23 Oct 1998 22:00:01 -0700 (PDT) Date: Fri, 23 Oct 1998 22:00:01 -0700 (PDT) Message-Id: <199810240500.WAA11830@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: John Birrell Subject: Re: kern/8375: pthread_cond_wait() spins the CPU Reply-To: John Birrell 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: John Birrell 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