Date: Tue, 12 Sep 2000 01:28:01 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Daniel Eischen <eischen@vigrid.com> Cc: Jason Evans <jasone@canonware.com>, Greg Lehey <grog@lemis.com>, arch@FreeBSD.ORG Subject: Re: Long-term mutex ownership (was Re: Interruptable mutex aquires.) Message-ID: <20000912012801.G12231@fw.wintelcom.net> In-Reply-To: <Pine.SUN.3.91.1000911224108.11203A-100000@pcnet1.pcnet.com>; from eischen@vigrid.com on Mon, Sep 11, 2000 at 11:07:56PM -0400 References: <20000911192610.D12231@fw.wintelcom.net> <Pine.SUN.3.91.1000911224108.11203A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Daniel Eischen <eischen@vigrid.com> [000911 20:08] wrote: > On Mon, 11 Sep 2000, Alfred Perlstein wrote: > > * Jason Evans <jasone@canonware.com> [000911 19:24] wrote: > > > On Tue, Sep 12, 2000 at 11:41:54AM +0930, Greg Lehey wrote: > > > > I think we need to come to some kind of consensus about how we are > > > > going to structure locking before we go into this much detail. At the > > > > moment we don't even agree whether we can hold on to (blocking) > > > > mutexes for long periods of time. > > > > > > I don't recall the original argument against holding mutexes for long > > > periods. From an abstract point of view, there's nothing wrong with such > > > practice, and in fact it makes sense for many problems. Is there an issue > > > with our implementation? If so, can someone please explain it? > > > > You are currently unable to abort if a signal comes in. :) > > > > Conditional variables add overhead and complexity where it's > > not needed. > > On the contrary. Our current mutex scheme with all the flags is > not as simple and as easy to understand as other OS kernel mutexes > I've dealt with. Having flags to mtx_enter() makes it more error > prone and I'd rather just use the mutex as it was mtx_init()'d. > I don't even want recursive mutexes and think that simple mutexes > with separate count fields should be used (I would probably lose > this argument though). > > Condition variables are used when you plan on waiting for something, > like I/O completion. You can wake one or all threads waiting on > condition variables. This is not typical of mutexes. Our current > splXXX()/tsleep()/splx() scheme corresponds very nicely with > mtx_enter()/cv_wait()/mtx_exit(). I don't recommend obfuscating > mutexes even more by creating yet another variant to be used > in place of tsleep() or cv_wait(). It's amazing what a rum and coke can do for one's concentration, you guys are right and I wish someone had looked at the code I was trying to work with, shook me and said "Alfred, you dumbass!" but then again I only have myself to blame here. :) The socketbuffer stuff is a prime example of what needs conditional variables and I didn't realize I was rolling my own using flags and msleep. *sigh* :) I am going to grep the Linux kernel and see if they have any examples of where an interruptable mutex is needed, but for now I don't need it and conditional variables would seem to be a nice thing. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000912012801.G12231>