Date: Tue, 20 Dec 2011 14:34:54 -0000 From: "Niall Douglas" <s_sourceforge@nedprod.com> To: freebsd-threads@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> In-Reply-To: <201112200822.26369.jhb@freebsd.org> References: <Your message of <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com>, <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com>, <201112200822.26369.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=EFve 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 f= or > atomic operations (e.g. only an exchange instruction or a single-bit tes= t-and- > set as opposed to a full-world test-and-set such as cmpxchg on x86 or ca= s 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 us= e > 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 obje= cts on > the stack of those threads. There is not a single magical stack size th= at > 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 functionali= ty 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF09D0E.14095.B663FD3C>