Date: Thu, 25 Sep 1997 10:40:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bde@zeta.org.au (Bruce Evans) Cc: gibbs@plutotech.com, julian@whistle.com, bde@zeta.org.au, current@FreeBSD.ORG, nate@mt.sri.com, tlambert@primenet.com Subject: Re: new timeout routines Message-ID: <199709251040.DAA16218@usr03.primenet.com> In-Reply-To: <199709250838.SAA06295@godzilla.zeta.org.au> from "Bruce Evans" at Sep 25, 97 06:38:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
This is getting quoted a lot... otherwise I won't try to correct it. > >there is an assumption in a lot of code that untimeout is idempotent > >(did I get that right?). It can be called whenever you are recovering > >from unknown situations with the sure knowledge that the appropriate > >timeout will be removed. > > This was an invalid assumption, since timeout() was only (almost) > nilpotent (calling it N+1 times has the same effect as calling it N > times for some value of N, provided there are no calls to timeout() > mixed with the calls to untimeout()). > > Now it is (almost) idempotent (N = 1 in the above), provided the > cookies are managed properly. Correct cookie management corresponds > to using the correct value of N in the old version. Actually, this is "called reflexively". Idempotence refers to the property of an operation wherein the operation may encapsulate multiple atomic operations as if it were itself atomic; it's more of an identity function for the set of operations that it encapsulates. A file rename operation may be idempotent, without there being only a single atomic operation involved. Main Entry: idempotent Pronunciation: 'I-d&m-"pO-t&nt Function: adjective Etymology: Latin idem same + potent-, potens having power -- more at POTENT Date: 1870 : relating to or being a mathematical quantity which when applied to itself under a given binary operation (as multiplication) equals itself; also : relating to or being an operation under which a mathematical quantity is idempotent - idempotent noun I don't think the code is assumed to be idempotent. I think it is assumed to be called reflexively (ie: one and only one deregistration called per registration). As others have pointed out, this is not a requirement, since you can sense stale cookies in the new scheme, and you can see the nulled out function entries in the old. It's more a rule of thumb. I don't think it's a bad thing for reflexive calling to become a requirement, where there is only a single deregister per register, or a single implicit deregister as a result of the timer firing (my "reschedulable one-shots" require an idempotent implicit deregister followed by explicit register in order to simulate a periodically scheduled event ;-)). All of the current lock code is reflexive, for example. The vnode lookup code in namei() is not (for another example). The vnode locking is not idempotent because of the possibility recursion (for yet another). If you want to be a real propeller-head (like me ;-)), you can read about Godel's Theorem and the mathematical definition of "completeness"; most of my whining about interfaces has to do with provability of "completeness" in the rigorous mathematical sense. Look up "+branch +path +analysis" on AltaVista, or read the book "code complete" for a higher level overview. If you do the AltaVista thing, you will at least get a useful tool in C++ for processing C code and producing test code out of it. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709251040.DAA16218>