Date: Fri, 27 Feb 1998 21:26:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jlemon@americantv.com (Jonathan Lemon) Cc: eivind@yes.no, fs@FreeBSD.ORG, jlemon@americantv.com Subject: Re: syncer / SMP question Message-ID: <199802272126.OAA24114@usr05.primenet.com> In-Reply-To: <19980227135733.19894@right.PCS> from "Jonathan Lemon" at Feb 27, 98 01:57:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> IMHO, all the original code really needs is a nice little comment stating > that vfs_busy() releases the lock on the mountlist if it succeeds. Yes; for now that's what should be done, instead. I found the macros obfuscatory as well. My suggestion was a style change, if you'll remember... > I'll also note that it appears possible to pass a NULL third argument to > vfs_busy() and thus have it not release the lock on the mountlist. Then > simple_unlock would be called explicitly in the sync() function, also making > things clearer. I don't know if this would be correct. The way it's written now allows interleaved access to work. The mountlist isn't reordered, generally. You'd have to pretend, in your mind, that someone is rotoring through mounts of three FS's, two at a time, before you'd have a nice model of a situation where a conflict could occur; even then, I think you'd have to be at a specific place in walking the list while this was happening, since if you weren't where the links were actively bouncing, it's a non-problem. > I'm unsure if the lock release done by vfs_busy/lockmgr was for > 1) convenience, or 2) some form of atomic unlocking. Perhaps someone > else could explain? Terry? Poul? I can't explain. I didn't write that code, and I pretty much hate a lot of it. For me to be able to explain, I'd have to "play computer" and walk it looking for cycles given the suggested changes. This would be a lot easier for me with: o A call graph in hand o Header block comments on the function that I can sed out into my call graph so I can watch the lock states transiting I can get the first, but I have to do the second in my head; it's not really worth doing this to code that is relatively inoffensive compared to some of the more glaringly offensive code that's there for me to stare at instead (NFS, anyone?). Frankly, it's just as easy for someone else to "play computer" as it is for me, but I think that doing so in this case would be beside the point. If you fix the big problems, the small ones take care of themselves. A friend of mine likes to say this another way: "Obstacles are what you see when you take your eyes off your goals". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802272126.OAA24114>