[Patch] C1X threading support
Niall Douglas
s_sourceforge at nedprod.com
Tue Dec 20 14:34:56 UTC 2011
On 20 Dec 2011 at 8:22, John Baldwin wrote:
> > 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.
>
> Mmmm, you might be well served to check up on the experience of some of
> the folks you are conversing with. Otherwise you risk reducing your
> credibility in the present forum. Also, to argue that "everything" in
> a standard is perfect is, eh, a bit of a stretch. There's a reason for
> the connotation associated with the phrase "design by committee".
That's not what I said John, and I object to you saying that I did. I
said, very specifically, that everything is the way it is for a good
reason. I did not at any stage suggest it was perfect, or right, or
even wise.
A good reason could mean that a vendor may have objected and said
very specifically that if feature X was (not) in there they would
refuse to support the whole thing, or pull resources, or do something
else bad. Much of standards setting is negotiating a common
denominator.
Does this lead to bad engineering? Absolutely yes. Does this lead to
stupid design? Absolutely yes. But I can absolutely assure you that
there was a good reason for most of the bad decisions and bad choices
in there.
> > > 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.
>
> Err, no, there should be no races here.
Sorry, I meant race conditions in the way a typical end user
programmer might naively choose to use it. A lot of APIs were dropped
or modified to help inhibit the damage from naïve use.
I might add there is absolutely no reason why implementations can't
add _np extensions. The spec might even add them in a later TR if
they prove common enough. For example, I'd like thread_timedjoin() in
there, but I'll have to get Austin to sign off on pthread_timedjoin()
first.
> The reason I can think of why you might not specify
> this is if you want to support machines that have very limited support for
> atomic operations (e.g. only an exchange instruction or a single-bit test-and-
> set as opposed to a full-world test-and-set such as cmpxchg on x86 or cas on
> sparc).
C11, controversially, requires at least atomic boolean support if the
threading module is supported. Of course you can build everything
else from this internally.
> > > 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 guess you don't want any popular software (e.g. Python) to actually use
> your API then. :) Sadly, there is some code that wants to create a
> bazillion threads in a given process and there is other code that wants to
> create a few threads but use deep call stacks and/or put some large objects on
> the stack of those threads. There is not a single magical stack size that
> works equally well for both. I agree that it is very MD and hackish to let an
> application specify the size directly, but unfortunately the functionality is
> necessary.
On ARM the stack need not be contiguous and is address space is
allocated on demand - was it in 1Mb chunks back in the day? I can't
remember. The problem with needing to specify stack sizes on x86 is a
fault of the x86 ABI not being able to demand allocate address space.
It could be fixed.
Generally, in C11 any unsafe operations or operations which were
deemed as being too platform specific weren't included. Almost
certainly judgement mistakes were made here. This is why TRs are
issued, a bit like service packs for the standard.
During your guys implementation of C11 do feel free to add _np
functions where you feel you need them. Even better push them at the
gnuc mailing list so some standardisation can be attempted. If BSD
and GNU both use a particular _np variant, it has a very good chance
of getting into the next TR.
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