>> What's kernel_lock? man -k turns up nothing; some grepping leads me >> to think it's what I've seen called on the lists a `giantlock', >> which is what I thought all this new locking stuff was supposed to >> be getting away from. > Yes, there is a giant lock. Some parts of the kernel need to have > that lock to work correctly. [...]
So the giantlock still exists because it's in a process of transition right now? Got it...I think. > Arguably each driver should havea comment, but the lack of MPSAFE in > flags (and an easy-to-overlook 0 instead!) is how you can tell; that > means that drivers written for the good old days of a (single) PDP-11 > cpu still work safely. Okay. I don't think I can rely on that, though, because the things I'm porting that have led me to care about locking are not just device drivers. One of them is a new socket address family (AF_TIMER - basically, a file descriptor attached to a setitimer-style timer) and the other, while it has a device driver interface, is also called into from various places in the disk drivers, disk drivers which may or may not be MPSAFE themselves. I have them working; I'll use them for a while and see if I have any reason to think I've gotten the locking wrong. Perhaps fortunately, most of my 5.2 machines are multiprocessor, so locking mistakes probably will get noticed eventually - especially since I was generous with my KASSERT()s, and have DIAGNOSTIC and DEBUG turned on. > It's a fair point about memory barriers and mutexes; I had never > thought of that. It _is_ easy to miss. Locking is full of subtle cases, and so is memory caching and reordering; put the two together and it's a wonder any of this stuff works at all. > I would say that the mutex should ensure that no instructions > From=20aother program post enter can issue until after the exit is > called, Basically, yeah: given thread 1 does: A(); enter; B(); ... C(); exit; D(); thread 2 does: E(); enter; F(); ... G(); exit; H(); then the mutex - I'm talking abstract mutexes in general, now, not what NetBSD's mutexes do - ensures that the F()...G() sequence occurs either entirely before B() or entirely after C(), and, similarly, the B()...C() sequence occurs either entirely before F() or entirely after G(). (A() through H(), here, are arbitrary operations, not just function calls, of course. Writing them as function calls is just notational convenience.) But this applies to instruction issue, which bears less relationship than one might wish to when stores reach global visibility and when loads start and complete. > but it then seems obvious that without memory barriers this isn't a > useful guarantee. Well, I wouldn't go that far, but it's less useful than it otherwise could be. In the abstract, it's perhaps better if the mutex operations do not entail memory barriers; that way uses that don't need memory barriers don't have to pay the costs of them, and the uses that do want memory barriers can insert them themselves. But, since few-to-none of the people writing the relevant code will totally grok this stuff, and since almost all of the uses will want the memory barriers, I think having the mutex calls make memory-barrier promises is a Right Thing. > It would be nice if someone who really gets this added a line to the > mutex man page, ideally referring to the memory barrier specs. I agree. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B