From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 14:34:56 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE891065676 for ; Tue, 20 Dec 2011 14:34:56 +0000 (UTC) (envelope-from s_sourceforge@nedprod.com) Received: from europe2.nedproductions.biz (unknown [IPv6:2a02:748:100:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id EA6528FC0A for ; Tue, 20 Dec 2011 14:34:55 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 1F9179EE476; Tue, 20 Dec 2011 14:34:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324391695; bh=NPk10jPYOooIWNbSYNAfDuZATEoyguKHgtKLforTJcA=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=m93bWvqh2S+oVb/MOW5gTH0lrmwL5pS4HHlD5S/X3fLhKPpQLJ06OPXmGn0bGNPhu mrNPxMt/JiAjyp1B2BakCWVT5KjH42AjWxl9cFPww8idFlzgpAqk9aoTiJxAMd7wmT Cu0a4FHvvUr+eXWiNCwmIsxZcKnp0shDtFLRDhUw= X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on europe2.nedproductions.biz X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from [192.168.2.8] (dsl-076-041.cust.imagine.ie [87.232.76.41]) by europe2.nedproductions.biz (Postfix) with ESMTPSA id 97A809EE476 for ; Tue, 20 Dec 2011 14:34:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324391694; bh=NPk10jPYOooIWNbSYNAfDuZATEoyguKHgtKLforTJcA=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=QiSHOPiY3I+VRrGv8VFTZG6udj35UMoYWgf4QygOGVmpvNK8/QPhsRmqrSKQbEayD 4TnBfjTW7XcPAyF/yYvAscqGhOvwead+ao5WB59W4tTVj5Xv8BopIso05VPiNql2tZ PkUS9nVFnOzZXfW8JY8TAGeslDDZKTvMStSCkiOE= From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 20 Dec 2011 14:34:54 -0000 MIME-Version: 1.0 Message-ID: <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <201112200822.26369.jhb@freebsd.org> References: , <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com>, <201112200822.26369.jhb@freebsd.org> X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:34:56 -0000 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.