[Patch] C1X threading support
Niall Douglas
s_sourceforge at nedprod.com
Thu Dec 22 16:57:42 UTC 2011
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.
More information about the freebsd-threads
mailing list