Date: Thu, 22 Dec 2011 16:57:38 -0000 From: "Niall Douglas" <s_sourceforge@nedprod.com> To: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com> In-Reply-To: <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> References: <78246.1324394062@critter.freebsd.dk>, <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Dec 2011 at 10:22, Warner Losh wrote: > When time changes in the system, as it is wont to do occasionally, then > absolute time arguments will screw you. There's no way to get them > right that isn't a massively horrible kludge. Let's say you want to > sleep for no more than 1s. You get the time, add 1s to it, get > preempted, ntpd or somebody else notices the clocks are 1 year fast and > adjusts, you get a quatum again and make the call with a timeout now > 1-year in the future. > > What could possibly outweigh that negative? As I said earlier, I don't remember what the reason was. And no, that doesn't mean it wasn't important - there is a vast volume of stuff being thrown at you during standards, if you can remember something from even a month ago you're doing well. That's why all decisions are documented in depth so it can get looked up later. Instead of shouting at me - who is trying to help you - go look it up if it matters so much to you. However, if I had to take a guess, I'd say that functional reliability can be higher when you can offer guarantees. Absolute times have higher potential of guarantees than relative, whereas the opposite is not true, because you can draw lines in the sand with absolute times and that's much harder with relative. You can also implement relative using an API taking absolute easily, whereas again the opposite is harder. I can see arguments for very long lived systems where uptime is typically in years that absolute would be a lot more reliable due to relative period drift e.g. if I want to be woken on the hour every hour, you don't want to be using a relative wait. Of course, you can then pull the system time and calculate the delta, but I digress. The point is that more information supplied to the kernel is usually better. Absolute times supply more information than relative. So there you go - and please note this paragraph is my best guess, and may have nothing to do with committee opinion. Instead of people repeatedly whinging about the system clock moving - and yes, people on standards committees are aware that system clocks can move, as they are that different cores can have different system clocks - I would be asking how does your scheduler cope with the clock moving, and how should clock syncs interact with userland? Be engineers instead of children. Ask how to solve the problem instead of complaining about split milk. Be glad you're implementing this on a POSIX system and not a non-POSIX system. Be glad there aren't a million lines of new code being needed to achieve compliance. The standard is now written in stone and is a full ISO/IEC document. Your time for helping shape it is over - we're in errata and bug fixing stage now. You should have been whinging a year or two years ago - it's not like the standard is a surprise to anyone paying attention. Its release date was widely publicised and draft spec documents are freely available over the past 18 months. I might add the C11 spec passed its last meeting with no objection from any committee member. The ISO participants consider it finished. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF36182.29429.C1336CBC>