Date: Tue, 20 Dec 2011 12:50:48 -0000 From: "Niall Douglas" <s_sourceforge@nedprod.com> To: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> In-Reply-To: <3065.1324375763@critter.freebsd.dk> References: <Your message of "Tue, 20 Dec 2011 09:48:12 GMT." <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com>>, <3065.1324375763@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Dec 2011 at 10:09, Poul-Henning Kamp wrote: > >1. Because [...] > > Nice and fine. > > But can you explain, why the job is done so half-assedly ? The job was NOT done half-arsed. If you had any experience of sitting on these committees you would know how much dedication and effort is put into standards, especially JTC1 SC22 subcommittees. Every single API in there has been studied and pored over at length across multiple years. Everything is the way it is for a good reason. If it doesn't make sense to you that's most likely because you're not half as experienced or clever as you think you are. If you really want to know why something is the way it is, all discussion regarding all points is documented in full. > 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. > Why are timescale-issues not dealt with ? > > 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. There was a long and heated discussion about this over many months, but the committee decided on UTC as the least worst choice. 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. None of the timed functions in C11 should ever be used outside a loop which tests and rewaits if necessary. I agree this isn't clear from the spec, but the spec is not a programming manual. Failure to wrap all these calls in double checking loops is bad code which won't be reliable. > 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. 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?4EF084A8.32369.B604AD16>