Date: Sat, 24 Oct 1998 05:00:00 -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.FAA23686@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: Daniel Eischen <eischen@vigrid.com> Cc: 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:13 +0400 Daniel Eischen wrote: > I don't see any other way of making pthread_cond_[timed]wait > bulletproof without disabling scheduling. You shouldn't > allow nesting of spinlocks being taken if there is a chance > of creating a deadlock. Let's assume that you do not nest > the condition variable and mutex spinlocks. Why? Frankly, I don't see any harm here. Sure, it is not safe to _SPINUNLOCK the condition lock before pthread_mutex_unlock. So it has to be done in other way around. > You need to disable thread scheduling. The way I've done it, > it doesn't hurt anything and will prevent needless thrashing > of threads. You want mutex_lock and cond_wait and friends > to be atomic and this does that without needless thrashing. I don't think the "trashing" is dangerous. Spinlocks are held due to very short period of time (this is the main assumption in their design and implementation). The chances that a thread holding a spinlock will be preempted are very low. Even if the thread will be preempted, the chances that another thread will try to lock the same spinlock are low. 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.FAA23686>