Date: Tue, 20 Dec 2011 13:40:00 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Niall Douglas" <s_sourceforge@nedprod.com> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <62147.1324388400@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 20 Dec 2011 12:50:48 GMT." <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com>, "Niall Douglas" writes: >> Why are fundamentally and necessary programming tools, such as a >> "assert this mutex is held" missing ? > >I think that was rejected due to concerns about introducing race >conditions if I remember correctly. You'll generally find there is no >easy way of checking the state of anything threading related for the >same reason. BS: Show me a working implementation of a mutex where you cannot tell if the current thread holds the mutex when it is locked ? (Hint: add a variable to the mutex, protected by the mutex, storing the thread-id if the locking thread ? Nudge, nudge, wink, wink ?) >> For instance mtx_timedlock() operates only on the UTC scale. Where >> is the option to wait on an "elapsed time" timescale to not be hosed >> by ntpd(8) or root's setting the clock backwards during system >> startup ? > >If I remember correctly UTC was seen as the safest of all options >available. Annoying to program I agree, but definitely safer than >alternatives. No, actually UTC is much unsafer than the alternative, and in general much less useful and desirable for the same reasons it is unsafe. UTC as implemented on a computer is not a continuous timescale, it is not even an monotonic timescale if you are unlucky. The far too typical scenario is that you boot your system and then some minutes later NTPD will step your clock forwards if you're lucky, and backwards by a day if you're not. >mtx_timedlock() only *tries* to wait for a period up to the time >specified. It may return any time before then and indeed if the >system clock were changed I would expect it to early out with a >thrd_error. And I would expect that most implementations will not even think about that cornercase, and just do stupid things if the UTC time is stepped backwards. (Case in point: The Oracle databases freezing over the leap-second were caused by code that tried to work around broken standards in this particular space) But if this was a well-thought-out standard, instead of a half-assed job, it wouldn't matter what you and I expect: Then the standard would have said what to expect. >None of the timed functions in C11 should ever be used outside a loop >which tests and rewaits if necessary. A loop doesn't help you if the UTC time is stepped back 1 hour and your sleep was supposed to be only one second. > I agree this isn't clear from >the spec, but the spec is not a programming manual. Which only goes to show that the great stride in education which UNIX brought, has been missed widely by the ISO-C crew. How do you expect actual real-life programmers to know how to use this brittle API's, if you don't even give them an example to look at, or write about their major caveats in the spec ? And maybe, in trying to express that using a real-world example, the standards comittee would realize that UTC was a mistake, and changed the timeout argument to a relative time interval instead, like for instance the poll(2) system-call. >> Where did the ability to control a threads stacksize or other >> attributes go in thrd_create() ? > >I would assume that they were considered non portable due to vendor >objection. In particular, I remember an argument that thread >stacksize settings are dangerous and must be omitted. I would assume that the people who found it dangerous were morons without any actual real-life experience programming threads on computers with finite resources ? The way POSIX did that is far from a piece of beauty, but at least it provides a way to communicate such attributes. You are welcome to think that everybody in the ISO-C group is better and smarter than me. If they are, this standard doesn't show it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62147.1324388400>