Date: Fri, 19 May 2000 13:12:38 -0600 From: Chuck Paterson <cp@bsdi.com> To: Mike Smith <msmith@freebsd.org> Cc: Doug Rabson <dfr@nlsystems.com>, Wes Peters <wes@softweyr.com>, arch@freebsd.org Subject: Re: A new api for asynchronous task execution Message-ID: <200005191912.NAA11320@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
}Can someon that's familiar with both make a comparison between the BSD/OS }mutex and the Solaris 7 'turnstile' mutex implementation? I'm getting }the impression that the two are in fact extremely similar... The short answer is that they are reasonably similar. Solaris has features which we (BSD/OS) plan on adding, but don't effect the users of the mutex. It was a conscious decision to delay adding these features until we had more data about exactly how they should be implemented. We still haven't got to that stage. BSD/OS locks require that the type of lock be passed in when the lock is acquired or released. This removes a test for the common case. Actually looking a little more at the Solaris doc they get rid of the test in the common case and pay an even high price for spin locks. BSD/OS hangs the processes/threads which have blocked trying to acquire a mutex right off the mutex. In Solaris the queues appear to be else where, although they may only be logically else where. I can't really tell, but this really isn't the important part. What is important is that they have segregated mutexs. When acquiring or releasing a non spin mutex is contested a spin mutex is acquired while sorting things out. In the case of BSD/OS this a single mutex. I'm really don't know how adequate or better how inadequate this is. It unlikely to scale above 4, and I really don't know if it will make it that far. But it does make things much simpler and while the kernel isn't stable simplicity matters. If, more likely when, we find excessive contention on this mutex then we will add more. At this point you need to select a mutex to use. The grouping of the turnstile does this for Solaris. Going beyond a single scheduling mutex will cause us to do something similar. We have been using the term priority propagation. When a process blocks on a mutex the running priority is propagated to the holder of the mutex, if the holder is at a lower priority. As far as I can tell it is identical to the Solaris term priority inheritance. When I left Sun this had yet to be implemented but the need for it was certainly understood. Solaris's default mutexs are adaptive mutexs. Adaptive mutexs may spin for a bit before giving up and task switching. Currently BSD/OS's default mutexs task switch immediately when trying to acquire a mutex held by another task. This also is something we will almost certainly change as soon as we get some data about what sort of heuristics to apply. Chuck 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?200005191912.NAA11320>