On Mon, 27 Apr 2009, Stephen Hemminger wrote: > > All those references support my argument that the lock is being > used recursively in this case. What's so hard between understanding the difference between "used recursively" and "recursive lock"? THEY MEAN TWO TOTALLY DIFFERENT THINGS! The fact that you don't seem to understand that is one of the things I've been complaining about all along. So here's a final set of clue-bat: Clue bat #1: - "can be used in a recursive context" is not the same as "is recursive". Analogy time: Look at "strtok_r()", and the difference between that and "strtok()". "strtok_r()" can be used in a threaded environment. Does that mean that 'strtok_r()' is threaded? No. When you call 'strtok_r()', it's still signle-threaded - it's just that it _can_ be called in a threaded environment and then still has sane semantics. Now, replace "threaded" with "recursive". Do you get it? Clue bat #2: - a lock that can count does not mean that it is recursive. Counting and recursion are TWO TOTALLY DIFFERENT ISSUES. The "countingness" means that there can be multiple users inside of it, and that, in turn, implies that maybe it can be used in a recursive context. But again, counting and recursion are not about the same thing at all. Put another way: a read-write lock is not a "recursive lock" despite the fact that you can recursively take the lock for reading. It just happens to count readers, and allow more than one (from _any_ context, not just from the "same context"). Clue bat #3: - A recursive lock is very much _about_ recursion. It is explicitly about the fact that the _same_ thread re-enters the lock, not about another thread being in the locked region at the same time. See the difference? Big, big difference. A recursive lock will lock out other thread contexts, even if it allows the current one to recurse. Notice how the _only_ thing a recursive lock allows is that recursive behavior, and nothing else. IOW, a "recursive lock" is explicitly designed for recursion. But that doesn't mean that recursive algorithms cannot use functions that aren't. Can you use "memcpy()" in a recursive algorithm? Yes. Does that mean that "memcpy()" is suddenly a "recursive memory copy"? No. See the difference? Clue bat #3: - if you do not understand the difference between these two things, don't then try to claim that somebody _else_ who does understand it is "deluding himself". Analogy time: Ethernet and a modem line can both get you on the internet. Now, let's say that Mr Peter Paste-Eater has heard of ethernet, and knows you can get on the internet with an ethernet connection, but he happens to use a modem line to do it. Now, Peter Paste-Eater talks to you, and tells you he is connecting to the internet with ethernet, and proudly shows you his serial line and modem, and tells you how he uses ethernet to get onto the internet. You correct him, and tell him it's not ethernet. He argues for several days about how he gets on the internet, and that it must thus be ethernet, and that you're obviously just "deluding yourself". Now, can you see why people react badly to you talking about "recursive locks"? You're acting like Peter Paste-Eater calling his serial line ethernet. The fact that two _different_ things can be used for the same end result DOES NOT MAKE THEM THE SAME THING. In other words: - "Recursive locks" are different from reader-writer locks. - The ability to count is different from recursion, although in a lock it can obviously be _related_ to whether it can be used in a recursive environment or not. If you don't have a counter, you probably cannot recurse, but it's also not true that a counter implies that you always can. A traditional counting lock is the old-fasioned 'semaphore' we have, where the count allows for more than just simple mutual exclusion, and is used when you might want to allow concurrency, but need to limit it to some number 'n' (although, almost always, n==1) - What the netfilter code wants is simply not a recursive lock. It wants a form of locking that allows recursive _use_, but as mentioned, that is totally and utterly irrelevant from what we call it. You _could_ use a recursive lock for it. BUT NONE OF THE PATCHES THAT HAVE EVER BEEN POSTED HAVE BEEN RECURSIVE LOCKS! Nada. None. Zero. Zilch. So don't talk about recursive locks. Get it? Finally? Or are you going to continue to be that Paste-Eater guy who refuses to understand that he is talking about something else than ethernet? Linus -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
