Date: Tue, 12 Sep 2000 00:28:24 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Greg Lehey <grog@lemis.com> Cc: Joerg Micheel <joerg@cs.waikato.ac.nz>, Frank Mayhar <frank@exit.com>, John Baldwin <jhb@pike.osd.bsdi.com>, Mark Murray <markm@FreeBSD.ORG>, FreeBSD-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest.c randomdev.c yarrow.c yarro Message-ID: <Pine.BSF.4.21.0009120012350.70592-100000@beppo.feral.com> In-Reply-To: <20000912161928.C23948@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> I liked the model Sun chose for Solaris. They have mutex', rw_locks, > >> condition variables. I don't like semaphores. Mutexes are for short > >> locks. Condition variables are for long-term waits, they are associated > >> with a mutex. You can only sleep/wakeup a CV when holding the associated > >> with it, which prevents races. When having to sleep on a CV the kernel > >> would unlock the mutex and reaquire it for the running thread before > >> returning. > > > > It encouraged very sloppy programming. > > That begs the question "can you elaborate?". Sure. Rather than think about how locks and locking and interactions with code flow can affect system performance, a plethora of r/w locks and lock upgrades and downgrades, and cv signals *and* broadcasts, and so on and so and so on were made available. As a consequence, the original 1988 internal paper which described the architecture took until at least 1996 or so (about Solaris 2.6) until one could say that performance was back to decent levels. Some of the performance buyback was at least 3 distinct re-implementations of locks, but some was just a lot of steady cleanup of code over time. The point here is that a plethora of different locks fuzzes the fundamental issue which is how to write code that doesn't step on itself and doesn't have really peculiar performance affect. In contrast to Sun, Kubota had a spinlock in h/w with a 30us timeout which would blow the machine up if exceeded. The spinlock was either used as a mutex on data structures, or within a semaphore (to guard the count field) to gate threads into kernel code segments. Everything that could be done inside the Solaris kernel with literally an order of magnitude more locking primitives was able to be successfully done in the Kubota kernel (including, I may say, processor affinity and interrupt threads, which Solaris took years to get even close to implementing). This was with a fairly standard early SVr4 based kernel with some BSD additions (I worked mostly on IPI, SCSI and some buffer cache delwri cleanups). "There's nothing that increases the zest for living so much as the imminence of death". There's nothing that increases respect for SMP more than having the machine blow up on you because you didn't think the code flow through- you don't grab a lock and wait for an external device to do something. Bad Things Happen(tm). I believe that, *so far*, FreeBSD is taking a very good middle ground approach between these two extremes. In particular, the witness code approach from BSDi is avoiding the absolute chaotic nightmare that the three way clustercoitus that streams mux modules, non-recursive Mutexes (which is what Solaris locks are) and the 'unsafe_driver' global mutex to allow for non-SMP ready modules to exist with SMP-ready modules made of Solaris. A mechanism of locks in addition to something close the current sleep/wakeup mechanism should be sufficient. Please don't allow 'creeping featurism/comp sci 101' in. Rather than add in reader/writer locks- make the people asking for them *really* justify why they need the expense of a locking mechanism that will be around for years. What problem does it solve? Can the problem be solved by redoing the subsystem in question to be more SMP friendly? IMO, etc... I'm not trying to start a flame war here. I think everyone working on this stuff gets extra special credits. -matt 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.BSF.4.21.0009120012350.70592-100000>