Date: Mon, 25 Sep 2000 13:59:45 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <Pine.SUN.3.91.1000925134059.18678A@pcnet1.pcnet.com> In-Reply-To: <XFMail.000925100353.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Sep 2000, John Baldwin wrote: > > On 24-Sep-00 Daniel Eischen wrote: > > On Sun, 24 Sep 2000, John Polstra wrote: > > But you can't then use a recursive mutex in conjunction with msleep > > (cv_wait) which forces you to use yet another mutex. This is fine, > > but it adds confusion for the programmer. > > This is a problem. However, for one thing we currently have a > KASSERT() that panic's if you msleep() on a recursed mutex. However, > one could also change msleep() to function like mi_switch() does > with Giant and have it fully release the lock before sleeping, but > this probably would not be a Good Thing. A compile error is much better than a kernel panic. > > > Another thing, is in > > our support for recursive mutexes is that they make the calling > > conventions overly complex (with the silly flag argumuents to > > mtx_enter()). > > > Uhhh. With the exception of the mtx_enter() for sched_lock in > mi_switch() that specifies M_RLIKELY, all of the mutex flags > currently in use have _nothing_ to do with recursion. > MTX_DEF/MTX_SPIN are used to distinguish spin locks from sleep > locks. The use of those flags is another matter for discussion, > but the flags have very, very little to do with recursion. One of the reasons given for the mutex macros and flags is that the mutex type/options can be given without having to check the type/options in the mutex structure. If this isn't true, then get rid of the hideous flags to mtx_enter and mtx_exit. Optimize for a free lock, and take the hit and call a C program if the lock is held to check the mutex type and do the appropriate thing. > > > If we are going to support recursive mutex, I think it would be > > better to add separate calls/macros/data types to support them, > > so the the mtx mutexes can be simplified. Calls to mtx_enter > > with the recursive mutex type wouldn't even compile. > > Err, the recursive nature of the mutexes is very trivial. It > doesn't affect the complexity of the mutexes at all. Most of > the "complexity" in the mutex code lies in putting processes to > sleep and waking them back up again for sleep locks, and in the > currently broken and disabled code to propagate a sleeping > process' priority to the process holding the mutex it is waiting > for. I still claim that recursive mutexes should not be supported by our standard kernel mutex. If you want to add another set of data types and functions for recursive mutexes, OK fine. But with proper coding techniques, I don't see the need to hold a mutex after fiddling with whatever data item is being protected. Take the mutex, set the owner or increase the ref count held in the data item to be protected, and then release the mutex either with mtx_exit() or msleep(). -- Dan Eischen 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?Pine.SUN.3.91.1000925134059.18678A>