Date: Wed, 21 Oct 1998 03:12:40 +0400 From: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru> To: Daniel Eischen <eischen@vigrid.com> Cc: lists@tar.com, tejblum@arc.hq.cti.ru, current@FreeBSD.ORG, info@highwind.com Subject: Re: Another Serious libc_r problem Message-ID: <199810202312.DAA02588@tejblum.dnttm.rssi.ru> In-Reply-To: Your message of "Tue, 20 Oct 1998 11:45:50 EDT." <199810201545.LAA21709@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > > I don't think you want to wrap anything other than the condtion > queue and dequeue with the condition spin locks; they should be > used just to protect changing the condition variable. > > As long as you enqueue the condition variable before you unlock the > mutex, there should be no race conditions. > Well, specs says that mutex unlocking and enqueuing are atomic, so we may put it in the code ;-|. (Note also that mutex_unlock may fail.) Anyway, what if a rescheduling happens just after thread was enqueued for condition variable, and some other thread signaled the condition? Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810202312.DAA02588>