[Patch] C1X threading support

[Niall Douglas]

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.