From owner-freebsd-threads@FreeBSD.ORG Sun Dec 18 01:23:57 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E59001065670 for ; Sun, 18 Dec 2011 01:23:57 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 603158FC17 for ; Sun, 18 Dec 2011 01:23:57 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 16C206E4C; Sun, 18 Dec 2011 01:06:42 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7E6FB88FB; Sun, 18 Dec 2011 02:06:38 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Poul-Henning Kamp" References: <85477.1324155737@critter.freebsd.dk> Date: Sun, 18 Dec 2011 02:06:38 +0100 In-Reply-To: <85477.1324155737@critter.freebsd.dk> (Poul-Henning Kamp's message of "Sat, 17 Dec 2011 21:02:17 +0000") Message-ID: <86ty4y4rj5.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, threads@freebsd.org, Ed Schouten 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: Sun, 18 Dec 2011 01:23:58 -0000 "Poul-Henning Kamp" writes: > Ohhh, but I know: Lets make a rival to the POSIX threads, we can do it > much better and slightly incompatible, big market there I'm sure. That's not the point. The point is that C until now did not have a concurrency model. The threading API in itself is not important; I'm sure the committee knows perfectly well that nobody is going to use it. What's important is that the standard now defines how C behaves in a concurrent environment. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Sun Dec 18 11:55:10 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B76D106566B; Sun, 18 Dec 2011 11:55:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E4A6E8FC16; Sun, 18 Dec 2011 11:55:09 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBIBrR7V052781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Dec 2011 13:53:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBIBrRBJ063596; Sun, 18 Dec 2011 13:53:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBIBrQ7A063595; Sun, 18 Dec 2011 13:53:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 Dec 2011 13:53:26 +0200 From: Kostik Belousov To: Dag-Erling Sm??rgrav Message-ID: <20111218115326.GD50300@deviant.kiev.zoral.com.ua> References: <85477.1324155737@critter.freebsd.dk> <86ty4y4rj5.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ub6V6mHXHR6pEqUf" Content-Disposition: inline In-Reply-To: <86ty4y4rj5.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org, Poul-Henning Kamp , threads@freebsd.org, Ed Schouten 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: Sun, 18 Dec 2011 11:55:10 -0000 --ub6V6mHXHR6pEqUf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 18, 2011 at 02:06:38AM +0100, Dag-Erling Sm??rgrav wrote: > "Poul-Henning Kamp" writes: > > Ohhh, but I know: Lets make a rival to the POSIX threads, we can do it > > much better and slightly incompatible, big market there I'm sure. >=20 > That's not the point. The point is that C until now did not have a > concurrency model. The threading API in itself is not important; I'm > sure the committee knows perfectly well that nobody is going to use it. > What's important is that the standard now defines how C behaves in a > concurrent environment. Well, the reverse was exactly _my_ point. I cannot find the description of how the abstract C machine behaves, in the presence of multiple threads of execution. The atomics chapter covers only some special operations, which are added in the new revision. E.g., there is absolutely no mention of the memory changes visibility, or guarantees of atimicity of the assignments/reads etc. IMO, the threading was slapped nearby, and the standard is not useful as-is. I am sorry if I missed the parts. --ub6V6mHXHR6pEqUf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7t1DUACgkQC3+MBN1Mb4gUAwCg2c2BM7NGPRcI/wlKmRaZqAJR EtUAoMuh2Gm61rRBSXn5W+VfZsSlM8Ma =3FGP -----END PGP SIGNATURE----- --ub6V6mHXHR6pEqUf-- From owner-freebsd-threads@FreeBSD.ORG Sun Dec 18 13:27:44 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C109106574A; Sun, 18 Dec 2011 13:27:44 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id ECF1C8FC17; Sun, 18 Dec 2011 13:27:43 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id E2B0A3592DF; Sun, 18 Dec 2011 14:27:42 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id B56AB28468; Sun, 18 Dec 2011 14:27:42 +0100 (CET) Date: Sun, 18 Dec 2011 14:27:42 +0100 From: Jilles Tjoelker To: Kostik Belousov Message-ID: <20111218132742.GA52983@stack.nl> References: <20111216214913.GA1771@hoeg.nl> <20111216220914.GW50300@deviant.kiev.zoral.com.ua> <20111216221959.GB1771@hoeg.nl> <20111216223126.GX50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111216223126.GX50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, Ed Schouten , threads@freebsd.org 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: Sun, 18 Dec 2011 13:27:44 -0000 On Sat, Dec 17, 2011 at 12:31:26AM +0200, Kostik Belousov wrote: > On Fri, Dec 16, 2011 at 11:19:59PM +0100, Ed Schouten wrote: > > * Kostik Belousov , 20111216 23:09: > > > If application that does not use the new interface supposed to be > > > able to implement function with new names, then the not-underscored > > > symbols must be weak. > > For example when an application wants to implement its own functions > > that are named thrd_*(), for example? > Yes. The realistic example is the code written to C99/SUSv4 conformance > that happens to define thrd_. > It might be that easiest solution is to put the functions into > separate library, besides defining them weak. Another idea is to implement the functions as static inline (with the possible exception of thrd_create() and perhaps some more). This pollutes the namespace of C1x programs with pthread_* though. > > > Do you have reference to the draft ? > > Yes, sure: > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf > BTW, it looks not very useful to add a bunch of threading functions > without at least trying to specify the memory model. I see a discussion of the memory model in 5.1.2.4 Multi-threaded executions and data races. -- Jilles Tjoelker From owner-freebsd-threads@FreeBSD.ORG Sun Dec 18 15:28:53 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4240106566B; Sun, 18 Dec 2011 15:28:53 +0000 (UTC) (envelope-from BATV+6695f58bc8be10e6006b+3038+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:4830:2446:ff00:4687:fcff:fea6:5117]) by mx1.freebsd.org (Postfix) with ESMTP id 89A958FC16; Sun, 18 Dec 2011 15:28:53 +0000 (UTC) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1RcIfQ-0000eS-Pf; Sun, 18 Dec 2011 15:28:48 +0000 Date: Sun, 18 Dec 2011 10:28:48 -0500 From: Christoph Hellwig To: Poul-Henning Kamp Message-ID: <20111218152848.GA460@infradead.org> References: <20111216223126.GX50300@deviant.kiev.zoral.com.ua> <85477.1324155737@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85477.1324155737@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Cc: arch@freebsd.org, threads@freebsd.org, Ed Schouten 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: Sun, 18 Dec 2011 15:28:54 -0000 On Sat, Dec 17, 2011 at 09:02:17PM +0000, Poul-Henning Kamp wrote: > A "assert mutex is held" facility ? Or a full FreeBSD / Linux lockdep style lock order validation tool. I still don't understand how your are supposed to write correct userspace code using more than a hand full of synchronization primitives without that. From owner-freebsd-threads@FreeBSD.ORG Sun Dec 18 16:15:05 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6881065673; Sun, 18 Dec 2011 16:15:05 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id E590D8FC14; Sun, 18 Dec 2011 16:15:04 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id CEE6A2A28CD0; Sun, 18 Dec 2011 17:15:03 +0100 (CET) Date: Sun, 18 Dec 2011 17:15:03 +0100 From: Ed Schouten To: Jilles Tjoelker Message-ID: <20111218161503.GG1771@hoeg.nl> References: <20111216214913.GA1771@hoeg.nl> <20111216220914.GW50300@deviant.kiev.zoral.com.ua> <20111216221959.GB1771@hoeg.nl> <20111216223126.GX50300@deviant.kiev.zoral.com.ua> <20111218132742.GA52983@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vhOf6eAHdfH9MSjZ" Content-Disposition: inline In-Reply-To: <20111218132742.GA52983@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: threads@freebsd.org, arch@freebsd.org 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: Sun, 18 Dec 2011 16:15:05 -0000 --vhOf6eAHdfH9MSjZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jilles, * Jilles Tjoelker , 20111218 14:27: > Another idea is to implement the functions as static inline (with the > possible exception of thrd_create() and perhaps some more). This > pollutes the namespace of C1x programs with pthread_* though. Hmmm... Indeed. This would change the entire C1X threading API simply into a compile-time translation mechanism to pthreads. Unfortunately, it would make things like debugging a bit harder, as placing breakpoints on the functions become a bit harder. Are there any objections to such an approach? --=20 Ed Schouten WWW: http://80386.nl/ --vhOf6eAHdfH9MSjZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJO7hGHAAoJEG5e2P40kaK7XOsP/Rdn46756oot1DgWAvmLDGt8 pC2RhmwqU73w4vo9I3mRErTrbpQ398FUKMd/gouE4oqu4nOqVO/Hws2NjzmynWjv uldqrVQ1dSrS0qNrSuo9SP1D5dAdZkoa1DjS19Fp4eyxk5ipS9ZvG2oaWe8mrWto xiFLYFzAUUFOC3p+V+94vScziL+gyraQQZchfuSUkZHTQfBagmCfkMIxw6mACVpy 6y20xAKtyyPcfc76BesUHts/Tpx3vjPbMrrVP5yAJRtWRLDaDkfyn6+UhwGs3la5 rks+2saHfvtbAK3S6mHo1MReoQgfu7fy0OHzD6QzhIcwhbHyPWJHiX8lvkXVapJG 8dlEEFWQZNIKJB1+dEwVYWRGRNvXllxrxiuOvElnFSX8OONWCn8iSEnFKSP/+EWG L0n0Z5NNujHDewJ4LUpnZcad8Y8ck9w+FTy+WrF3SbXz7b+DC5Kd6ZFRWd+FMGUv epBgyeDo5q9dduvdaY2eNBQ6KjtOFvmGXo97eCh8laZt8IjNG33EoTQw+OF5zMup ZccnP2v8KbaQ286w6N8T4545Mn/qUi/KHtGzBCTIDrWq8ekWH4oWNyUzedaXE31R smm5XPNARFdbf3j6HFkS2JHZ4aU53ipS9BKg+gbHtRRYWHR24/FQ7FDLDazH1rpK kt5legthEuTkBZ3EH7eJ =lmo/ -----END PGP SIGNATURE----- --vhOf6eAHdfH9MSjZ-- From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 10:57:24 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75DF7106566B; Mon, 19 Dec 2011 10:57:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 327E98FC0A; Mon, 19 Dec 2011 10:57:23 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CF1585DC9; Mon, 19 Dec 2011 10:57:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBJAvLjX058924; Mon, 19 Dec 2011 10:57:21 GMT (envelope-from phk@phk.freebsd.dk) To: Tijl Coosemans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 19 Dec 2011 11:52:17 +0100." <201112191152.22907.tijl@coosemans.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 19 Dec 2011 10:57:21 +0000 Message-ID: <58923.1324292241@critter.freebsd.dk> Cc: threads@freebsd.org, freebsd-arch@freebsd.org 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: Mon, 19 Dec 2011 10:57:24 -0000 In message <201112191152.22907.tijl@coosemans.org>, Tijl Coosemans writes: >> Big/Little Endian API ? >> >> Naah, nobody moves binary data between computers. > >Yes, but rather than having the programmer remember when to swap bytes, >it would be better if he could just declare a variable big/little >endian and have the compiler figure it out. You'd think so, wouldn't you ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 11:02:42 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C44321065670; Mon, 19 Dec 2011 11:02:42 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1D28FC13; Mon, 19 Dec 2011 11:02:41 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGYV705bsVo6/2dsb2JhbABDqROCS4EGgXIBAQVWIxALGC45HgeIDrd5jAQEiAOfKg Received: from 58.90-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.90.58]) by relay.skynet.be with ESMTP; 19 Dec 2011 11:52:26 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.5/8.14.5) with ESMTP id pBJAqPv1003189; Mon, 19 Dec 2011 11:52:25 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org, threads@freebsd.org Date: Mon, 19 Dec 2011 11:52:17 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC2; KDE/4.7.3; i386; ; ) References: <85477.1324155737@critter.freebsd.dk> In-Reply-To: <85477.1324155737@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6161652.z3pzWeIXpR"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201112191152.22907.tijl@coosemans.org> Cc: Poul-Henning Kamp 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: Mon, 19 Dec 2011 11:02:42 -0000 --nextPart6161652.z3pzWeIXpR Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Saturday 17 December 2011 22:02:17 Poul-Henning Kamp wrote: > Big/Little Endian API ? >=20 > Naah, nobody moves binary data between computers. Yes, but rather than having the programmer remember when to swap bytes, it would be better if he could just declare a variable big/little endian and have the compiler figure it out. --nextPart6161652.z3pzWeIXpR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EABEIAAYFAk7vF2YACgkQfoCS2CCgtiuxZAD5Ac5JwKs79JJnqR+Wn0Juz4DQ T4Q/LMvyWINAgxW+iiYBAIdHumR1292ZBLPl/cyfWPWpkMRjooBBy8epG+lzrzsk =XjtJ -----END PGP SIGNATURE----- --nextPart6161652.z3pzWeIXpR-- From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 11:07:16 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 C74A8106566B for ; Mon, 19 Dec 2011 11:07:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7A28FC14 for ; Mon, 19 Dec 2011 11:07:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBJB7GIg011095 for ; Mon, 19 Dec 2011 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBJB7GQm011093 for freebsd-threads@FreeBSD.org; Mon, 19 Dec 2011 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Dec 2011 11:07:16 GMT Message-Id: <201112191107.pBJB7GQm011093@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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: Mon, 19 Dec 2011 11:07:16 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/157040 threads [libthr] valgrind detects leaks in libthr.so.3 o threa/154893 threads pthread_sigmask don't work if mask and oldmask are pas o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/34536 threads accept() blocks other threads s threa/30464 threads [patch] pthread mutex attributes -- pshared 25 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 15:05:46 2011 Return-Path: Delivered-To: threads@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B46D3106566C; Mon, 19 Dec 2011 15:05:46 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 776898FC0A; Mon, 19 Dec 2011 15:05:46 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pBJF5hQc031442; Mon, 19 Dec 2011 10:05:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pBJF5haX031441; Mon, 19 Dec 2011 10:05:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 19 Dec 2011 10:05:43 -0500 From: David Schultz To: Ed Schouten Message-ID: <20111219150543.GA31384@zim.MIT.EDU> Mail-Followup-To: Ed Schouten , Jilles Tjoelker , Kostik Belousov , threads@freebsd.org, arch@freebsd.org References: <20111216214913.GA1771@hoeg.nl> <20111216220914.GW50300@deviant.kiev.zoral.com.ua> <20111216221959.GB1771@hoeg.nl> <20111216223126.GX50300@deviant.kiev.zoral.com.ua> <20111218132742.GA52983@stack.nl> <20111218161503.GG1771@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111218161503.GG1771@hoeg.nl> Cc: threads@FreeBSD.ORG, arch@FreeBSD.ORG 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: Mon, 19 Dec 2011 15:05:46 -0000 On Sun, Dec 18, 2011, Ed Schouten wrote: > Hi Jilles, > > * Jilles Tjoelker , 20111218 14:27: > > Another idea is to implement the functions as static inline (with the > > possible exception of thrd_create() and perhaps some more). This > > pollutes the namespace of C1x programs with pthread_* though. > > Hmmm... Indeed. This would change the entire C1X threading API simply > into a compile-time translation mechanism to pthreads. Unfortunately, it > would make things like debugging a bit harder, as placing breakpoints on > the functions become a bit harder. > > Are there any objections to such an approach? Technically there's a requirement that external definitions be provided. Applications that break if you don't are pretty rare, but why not do it right by providing some wrappers or symbol aliases in the library? Nothing precludes you from also defining a non-static inline function in the header file (but note that you may need an ifdef to handle the differences between GNU and C99 inlines.) From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 15:37:28 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF5981065670; Mon, 19 Dec 2011 15:37:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 92FC08FC0A; Mon, 19 Dec 2011 15:37:28 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pBJFEjS5042732; Mon, 19 Dec 2011 10:14:45 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Mon, 19 Dec 2011 10:14:46 -0500 (EST) Date: Mon, 19 Dec 2011 10:14:45 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Schultz In-Reply-To: <20111219150543.GA31384@zim.MIT.EDU> Message-ID: References: <20111216214913.GA1771@hoeg.nl> <20111216220914.GW50300@deviant.kiev.zoral.com.ua> <20111216221959.GB1771@hoeg.nl> <20111216223126.GX50300@deviant.kiev.zoral.com.ua> <20111218132742.GA52983@stack.nl> <20111218161503.GG1771@hoeg.nl> <20111219150543.GA31384@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , arch@freebsd.org, threads@freebsd.org Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:37:29 -0000 On Mon, 19 Dec 2011, David Schultz wrote: > On Sun, Dec 18, 2011, Ed Schouten wrote: >> Hi Jilles, >> >> * Jilles Tjoelker , 20111218 14:27: >>> Another idea is to implement the functions as static inline (with the >>> possible exception of thrd_create() and perhaps some more). This >>> pollutes the namespace of C1x programs with pthread_* though. >> >> Hmmm... Indeed. This would change the entire C1X threading API simply >> into a compile-time translation mechanism to pthreads. Unfortunately, it >> would make things like debugging a bit harder, as placing breakpoints on >> the functions become a bit harder. >> >> Are there any objections to such an approach? > > Technically there's a requirement that external definitions be > provided. Applications that break if you don't are pretty rare, but > why not do it right by providing some wrappers or symbol aliases in > the library? Nothing precludes you from also defining a non-static > inline function in the header file (but note that you may need an ifdef > to handle the differences between GNU and C99 inlines.) I agree, we probably want external definitions in case one needs to interface to the functions from a different language. Also, please symbol version the library. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 17:19:23 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 371171065672; Mon, 19 Dec 2011 17:19:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E7F228FC12; Mon, 19 Dec 2011 17:19:22 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBJHA0NJ049289 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 19 Dec 2011 10:10:02 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <58923.1324292241@critter.freebsd.dk> Date: Mon, 19 Dec 2011 10:09:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58923.1324292241@critter.freebsd.dk> To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 19 Dec 2011 10:10:03 -0700 (MST) Cc: threads@freebsd.org, Tijl Coosemans , freebsd-arch@freebsd.org 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: Mon, 19 Dec 2011 17:19:23 -0000 On Dec 19, 2011, at 3:57 AM, Poul-Henning Kamp wrote: > In message <201112191152.22907.tijl@coosemans.org>, Tijl Coosemans = writes: >=20 >>> Big/Little Endian API ? >>>=20 >>> Naah, nobody moves binary data between computers. >>=20 >> Yes, but rather than having the programmer remember when to swap = bytes, >> it would be better if he could just declare a variable big/little >> endian and have the compiler figure it out. >=20 > You'd think so, wouldn't you ? Intel has a compiler that allows one to declare things are big or little = endian and then things work. A certain large router vendor used it to = port its software that was big endian only at a very deep layer to Intel = x86... Linux marks things as beXX or leXX and uses static analysis to prevent = mixing. There's a lot of prior art for the committee to choose from. Warner From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 17:30:56 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 613E2106566C; Mon, 19 Dec 2011 17:30:56 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBE18FC12; Mon, 19 Dec 2011 17:30:55 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8DF6C5DAA; Mon, 19 Dec 2011 17:30:54 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBJHUos4060234; Mon, 19 Dec 2011 17:30:54 GMT (envelope-from phk@phk.freebsd.dk) To: Warner Losh From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 19 Dec 2011 10:09:53 MST." Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 19 Dec 2011 17:30:50 +0000 Message-ID: <60233.1324315850@critter.freebsd.dk> Cc: threads@freebsd.org, Tijl Coosemans , freebsd-arch@freebsd.org 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: Mon, 19 Dec 2011 17:30:56 -0000 In message , Warner Losh write s: >There's a lot of prior art for the committee to choose from. Same thing for struct packing to match a protocol specification. And as for assert_mutex_held() I belive some of the prior art is only a few hours longer than the word "mutex". I really wonder what they think they are trying to do some times... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 17:47:21 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2ADA1065675; Mon, 19 Dec 2011 17:47:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 70CE38FC16; Mon, 19 Dec 2011 17:47:21 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6E0787300A; Mon, 19 Dec 2011 18:46:24 +0100 (CET) Date: Mon, 19 Dec 2011 18:46:24 +0100 From: Luigi Rizzo To: Warner Losh Message-ID: <20111219174624.GA13576@onelab2.iet.unipi.it> References: <58923.1324292241@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: threads@freebsd.org, Poul-Henning Kamp , Tijl Coosemans , freebsd-arch@freebsd.org 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: Mon, 19 Dec 2011 17:47:21 -0000 On Mon, Dec 19, 2011 at 10:09:53AM -0700, Warner Losh wrote: > > On Dec 19, 2011, at 3:57 AM, Poul-Henning Kamp wrote: > > > In message <201112191152.22907.tijl@coosemans.org>, Tijl Coosemans writes: > > > >>> Big/Little Endian API ? > >>> > >>> Naah, nobody moves binary data between computers. > >> > >> Yes, but rather than having the programmer remember when to swap bytes, > >> it would be better if he could just declare a variable big/little > >> endian and have the compiler figure it out. > > > > You'd think so, wouldn't you ? > > Intel has a compiler that allows one to declare things are big or little endian and then things work. A certain large router vendor used it to port its software that was big endian only at a very deep layer to Intel x86... > > Linux marks things as beXX or leXX and uses static analysis to prevent mixing. > > There's a lot of prior art for the committee to choose from. and that would be the definition of a blacklist, right ? :) cheers luigi From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 17:56:12 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAE081065670; Mon, 19 Dec 2011 17:56:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 711228FC18; Mon, 19 Dec 2011 17:56:12 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rch9e-000733-Rp>; Mon, 19 Dec 2011 18:37:38 +0100 Received: from e178006011.adsl.alicedsl.de ([85.178.6.11] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rch9e-0007oE-ND>; Mon, 19 Dec 2011 18:37:38 +0100 Message-ID: <4EEF765D.4090300@zedat.fu-berlin.de> Date: Mon, 19 Dec 2011 18:37:33 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Warner Losh References: <58923.1324292241@critter.freebsd.dk> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD4679509587AA80EFD2E8B74" X-Originating-IP: 85.178.6.11 Cc: threads@freebsd.org, Poul-Henning Kamp , freebsd-arch@freebsd.org 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: Mon, 19 Dec 2011 17:56:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD4679509587AA80EFD2E8B74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/19/11 18:09, Warner Losh wrote: >=20 > On Dec 19, 2011, at 3:57 AM, Poul-Henning Kamp wrote: >=20 >> In message <201112191152.22907.tijl@coosemans.org>, Tijl Coosemans wri= tes: >> >>>> Big/Little Endian API ? >>>> >>>> Naah, nobody moves binary data between computers. >>> >>> Yes, but rather than having the programmer remember when to swap byte= s, >>> it would be better if he could just declare a variable big/little >>> endian and have the compiler figure it out. >> >> You'd think so, wouldn't you ? >=20 > Intel has a compiler that allows one to declare things are big or littl= e endian and then things work. A certain large router vendor used it to = port its software that was big endian only at a very deep layer to Intel = x86... >=20 > Linux marks things as beXX or leXX and uses static analysis to prevent = mixing. >=20 > There's a lot of prior art for the committee to choose from. >=20 > Warner >=20 A silly question: How is the other BSD sibbling, NetBSD, dealing with such things? NetBSD is supposed to run on a trmendous variety of hardware, even a mixture of bigendian and littleenddian and I'm quite sure they must have overcome this probleme anyway. Regrads, Oliver --------------enigD4679509587AA80EFD2E8B74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO73ZiAAoJEOgBcD7A/5N8Yh4IALIrJvxbQWKmE1/SmOqDz84c WyBoUP6O3Rj816VFXM17Mda/YTG3+L11hYIVqIo/tKZO4knyj11IZ2nZUoiNfc9v PaULHHEVBNw7cNOa/fLUiV7H78dUL7galbEKvhMgKrT9Nbzh06UxlUZmOCZlhZGX 3PvG95m9STJb0Ex2UJnUPim/NmoNDvTOxB8mZjwSfjU89A/nk5a23SlOdsRNFJka XCjWejy0B9CMHGOWMSW/eJ46ePrM6gxpoIDA4vGmIaOlg7jGc7umi1e4dunCMZgY Xbl4gOhixbqaybXrvttRkrWENaA+6uqV5APY17hytK8Tk3sa0PgJQ20DNChrNzA= =FZfG -----END PGP SIGNATURE----- --------------enigD4679509587AA80EFD2E8B74-- From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 19:36:24 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF6F9106566B; Mon, 19 Dec 2011 19:36:24 +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 4252A8FC0C; Mon, 19 Dec 2011 19:36:24 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 6F2E69EE476; Mon, 19 Dec 2011 19:36:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323383; bh=1QF4rBK711EZyM5OzxYp09GQQj9AMrVMdAM6ayIdAUE=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=vxTycPicFNep/rmcti0SNE3xN3r1TEH7youbL2gu8ZVl6CElz/qj0GZPSxMYP4F1A oYE8IDXjxsa/k00JLXMm8rKYsP2RyuBNk0xdqLrxnmS/38EUL8c2OqH9baE2T16RCs FAi3WdB88zKDm5Vx5o8w4JjuG3pHiTwx76N7X63c= 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 E2F4C9EE473; Mon, 19 Dec 2011 19:36:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323382; bh=1QF4rBK711EZyM5OzxYp09GQQj9AMrVMdAM6ayIdAUE=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=Ti3NoZobz6rTyqmTioRZQaxd7qRLZdxVEiVLXdxCyfmgnmaSdIgvvwlT1toKPgJdG Hf25zcHG/OHEspb56Q948dfogHaFnwjDA1uNbOznCSsrRMUasKKlKf3j1CEz8XzqLC Kq9LNp4Tyt7RXVbgiVLYBKk4lsOO1QIYKOwe2ruI= From: "Niall Douglas" To: threads@freebsd.org, arch@freebsd.org Date: Mon, 19 Dec 2011 19:36:21 -0000 MIME-Version: 1.0 Message-ID: <4EEF9235.31023.B2519C9A@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <20111216214913.GA1771@hoeg.nl> References: <20111216214913.GA1771@hoeg.nl> X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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: Mon, 19 Dec 2011 19:36:24 -0000 On 16 Dec 2011 at 22:49, Ed Schouten wrote: > In my opinion the ISO folks suffer a bit from the Not Invented Here > syndrome. In an earlier revision of the C1X specification, they even > described a `struct xtime', which had a purpose identical to `struct > timespec'. The same holds for the threading API. It can be 1:1 mapped to > a subset of pthread -- why not simply standardize that subset then? As someone who sits on said committees, I can tell you that the reason why was because at the beginning it was thought that the C1X threading API would diverge significantly from the POSIX API. Indeed, early drafts of the standard had quite a number of changes. However, just recently almost all of those changes have been excised due to pressures from the system vendors and the C++ committee who came in quite late on wanting feature parity between the two, and C++ had chosen a specific subset of POSIX rather than doing anything to try and fix its known problems. Obviously, had we known that from the beginning, things would have been done differently. However, there was - in hindsight - a lack of realisation just how expensive any significant changes would appear to vendors. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 19:36:29 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC3E106564A; Mon, 19 Dec 2011 19:36:29 +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 B1AB98FC13; Mon, 19 Dec 2011 19:36:28 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 0968A9EE476; Mon, 19 Dec 2011 19:36:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323388; bh=kAA7hcQIbkEDdfBCWO/gz0tn+ryUvDyiHQL82jX1ZwE=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=sGN3zTM5wFrBsBycpiOOEU57fSC1yChY1WUMgnm0/uxoq+ThQpO5jUQf+aCUkBZCH y22yazHUejmqCgPs5dvvgUJp2ZLrPInKVutVcFxlCbLNMxJ3HbTn5L75dVJxFja/Kc WQdIo4PD/qp8MXUtuAe41aVYpt4f8K39lQP6njzg= 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 86D949EE473; Mon, 19 Dec 2011 19:36:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323387; bh=kAA7hcQIbkEDdfBCWO/gz0tn+ryUvDyiHQL82jX1ZwE=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=AEPh5XOpRcE+712kIFxhqbcav6QC5oO0HhOV52BVc9N9CgvwHknERvNYgSzHGLkK3 olbRU7zhEISxPbSy8xPDXwiMPcdDJIbVocY8uo7zmLB5J1Aztku6TpinFZAykUJ5kx GUwNeGeBtgv4uym0Drkc9PbubqJ3zutIFN9oVMME= From: "Niall Douglas" To: arch@freebsd.org, threads@freebsd.org Date: Mon, 19 Dec 2011 19:36:21 -0000 MIME-Version: 1.0 Message-ID: <4EEF9235.252.B2519BEE@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <86ty4y4rj5.fsf@ds4.des.no> References: <85477.1324155737@critter.freebsd.dk>, <86ty4y4rj5.fsf@ds4.des.no> 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 Cc: 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: Mon, 19 Dec 2011 19:36:29 -0000 On 18 Dec 2011 at 2:06, Dag-Erling Sm=F8rgrav wrote: > "Poul-Henning Kamp" writes: > > Ohhh, but I know: Lets make a rival to the POSIX threads, we can do i= t > > much better and slightly incompatible, big market there I'm sure. > > That's not the point. The point is that C until now did not have a > concurrency model. The threading API in itself is not important; I'm > sure the committee knows perfectly well that nobody is going to use it. > What's important is that the standard now defines how C behaves in a > concurrent environment. Actually we don't go far enough at all in specifying how C behaves in a concurrent environment. The problem is that in the expected lifetime of the standard (10 years) there are a number of known big changes coming to commodity hardware e.g. memory transactions and non-SMP cache coherency. No one on the committee wants to accidentally break future hardware features, so we have left them unspecified. BTW we entirely expect the C1X threading API to supplant all others, including POSIX whose threading support will be mostly for backwards compatibility and may even become deprecated. A lot of resources and effort has been directed into getting the memory model right and future safe if not future proof. Indeed, the chances are that the next POSIX revision will copy C1X in some areas rather than the other way round. The complaints about API bloating are obvious. Bear in mind that while POSIX based platforms are in a majority, there are significant large implementors of C1X for whom a lot of new support code will have to be written e.g. MS Windows, whereas POSIX platforms have a much easier time of things in supporting C1X. Regarding implementing support for the C1X threading API, I'd suggest a different approach. Windows PE and Apple Mach-O both support symbol aliasing so you can declare an API to be identical to another API. Interestingly, ELF has no such feature. See http://blog.omega-prime.co.uk/?p=3D121. I would suggest the best and easiest way to implement much of the C1X library is to add symbol aliasing to ELF. Then all ELF binary based systems could support C1X features without having to resort to inline headers or thin wrappers. Linux will be needing this too, and it's the easiest way out. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 19:36:30 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 400B2106566C; Mon, 19 Dec 2011 19:36:30 +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 EA21A8FC14; Mon, 19 Dec 2011 19:36:29 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 5DF229EE476; Mon, 19 Dec 2011 19:36:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323389; bh=NVPtnDWhDNEITJK+bcS6IRQnTY8syOaj+spP+Xoudx8=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=vWeRNEQ0Er2Hm5IARfynS2Bui6ZvxFFdHuXzfluOY/5lNrLEuJ+J1yv7cuu2FzGjq elziyDCIJdumvwAghskDTBwpKVECuQoAGOOn/L5PfdFDXM+f+bz3UxkfLFoKhUZVVz RKg6g25UnyK4UHEkK4lk812jo0BggudM43tZ2qiI= 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 7EF569EE473; Mon, 19 Dec 2011 19:36:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323388; bh=NVPtnDWhDNEITJK+bcS6IRQnTY8syOaj+spP+Xoudx8=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=lBfkP+7poaxo+O3wkYbWEkX8pqqeTfTPazmMupvqSFBhJlNY8pMnshNvh1TZybi9D 4UNA/mzuvneMcAwCO98y5m+vdztii+pAkCwwdEimm5OVCnlokD0H7ZKtih8786vNCZ 2ZjCVMr5fpzhu6jPhH2AKghf6ohuExrRqafv+rr8= From: "Niall Douglas" To: arch@freebsd.org, threads@freebsd.org Date: Mon, 19 Dec 2011 19:36:21 -0000 MIME-Version: 1.0 Message-ID: <4EEF9235.24779.B2519D55@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <20111218115326.GD50300@deviant.kiev.zoral.com.ua> References: <85477.1324155737@critter.freebsd.dk>, <86ty4y4rj5.fsf@ds4.des.no>, <20111218115326.GD50300@deviant.kiev.zoral.com.ua> X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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: Mon, 19 Dec 2011 19:36:30 -0000 On 18 Dec 2011 at 13:53, Kostik Belousov wrote: > Well, the reverse was exactly _my_ point. I cannot find the description of > how the abstract C machine behaves, in the presence of multiple threads > of execution. The atomics chapter covers only some special operations, > which are added in the new revision. Indeed. It is deliberately unspecified. > E.g., there is absolutely no mention of the memory changes visibility, > or guarantees of atimicity of the assignments/reads etc. IMO, the threading > was slapped nearby, and the standard is not useful as-is. I am sorry if > I missed the parts. The memory model has been very closely thought through by some of the leading domain experts in the area. What the C1X standard refers to is per-CPU core, so if you do an acquire, acquire, acquire, release, acquire then you get a certain guaranteed minimal ordering of reads and writes on that particular CPU core as seen from other cores. Note I used the condition "minimal". The whole point of acquire/release is that the maximum degree of freedom to reorder is given to both the compiler and the CPU. Note that the CPU may ignore the ordering internally so long as externally the validity of the ordering is maintained. For example, if a cache line is exclusive to a core and no other core has it, the CPU may dispense with any ordering constraints within that cache line. This obviously has no bad consequences. Right now Intel x86/x64 has an extremely tight memory model - all loads acquire and all stores release unless you use special SSE/AVX opcodes to say otherwise. This means that code which works great on Intel can randomly fail on other processors. It's worth bearing this in mind. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 19 22:31:59 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 156911065675; Mon, 19 Dec 2011 22:31:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C7C848FC15; Mon, 19 Dec 2011 22:31:58 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pBJMVvED021175; Mon, 19 Dec 2011 17:31:57 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Mon, 19 Dec 2011 17:31:57 -0500 (EST) Date: Mon, 19 Dec 2011 17:31:57 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Niall Douglas In-Reply-To: <4EEF9235.31023.B2519C9A@s_sourceforge.nedprod.com> Message-ID: References: <20111216214913.GA1771@hoeg.nl> <4EEF9235.31023.B2519C9A@s_sourceforge.nedprod.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:31:59 -0000 On Mon, 19 Dec 2011, Niall Douglas wrote: > On 16 Dec 2011 at 22:49, Ed Schouten wrote: > >> In my opinion the ISO folks suffer a bit from the Not Invented Here >> syndrome. In an earlier revision of the C1X specification, they even >> described a `struct xtime', which had a purpose identical to `struct >> timespec'. The same holds for the threading API. It can be 1:1 mapped to >> a subset of pthread -- why not simply standardize that subset then? > > As someone who sits on said committees, I can tell you that the > reason why was because at the beginning it was thought that the C1X > threading API would diverge significantly from the POSIX API. Indeed, > early drafts of the standard had quite a number of changes. However, > just recently almost all of those changes have been excised due to > pressures from the system vendors and the C++ committee who came in > quite late on wanting feature parity between the two, and C++ had > chosen a specific subset of POSIX rather than doing anything to try > and fix its known problems. > > Obviously, had we known that from the beginning, things would have > been done differently. However, there was - in hindsight - a lack of > realisation just how expensive any significant changes would appear > to vendors. And why on earth would the thought of having a threading API significantly different from the POSIX API even be on the table? It boggles the mind. -- DE From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 09:48:13 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47F381065676; Tue, 20 Dec 2011 09:48:13 +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 B494E8FC0C; Tue, 20 Dec 2011 09:48:12 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id DAE659EE476; Tue, 20 Dec 2011 09:48:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324374491; bh=Rs69jaibQ1OZrqifUeiHb8XS3MKtN3hE9gJpzqpcTAs=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=cqlLV1ms0cUCUb7Z55qjpCBgLX49PjznSPpehdzZRZM1IF8aiCfBsUjvJ5d1zn1bF 2x66nnKdCFnDYFFXq7b/T4+dm+aPutTrlSNHP/6gvAmOuC8P5Fc+GaQXmmwUQjv2/7 bnSUYEIMv+PXpXf07UIOUpISvMr+ltD2hPRyYU+8= 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 D1BB79EE241; Tue, 20 Dec 2011 09:48:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324374491; bh=Rs69jaibQ1OZrqifUeiHb8XS3MKtN3hE9gJpzqpcTAs=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=cqlLV1ms0cUCUb7Z55qjpCBgLX49PjznSPpehdzZRZM1IF8aiCfBsUjvJ5d1zn1bF 2x66nnKdCFnDYFFXq7b/T4+dm+aPutTrlSNHP/6gvAmOuC8P5Fc+GaQXmmwUQjv2/7 bnSUYEIMv+PXpXf07UIOUpISvMr+ltD2hPRyYU+8= From: "Niall Douglas" To: threads@freebsd.org, arch@freebsd.org Date: Tue, 20 Dec 2011 09:48:12 -0000 MIME-Version: 1.0 Message-ID: <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> Priority: normal In-reply-to: References: <20111216214913.GA1771@hoeg.nl>, <4EEF9235.31023.B2519C9A@s_sourceforge.nedprod.com>, X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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 09:48:13 -0000 On 19 Dec 2011 at 17:31, Daniel Eischen wrote: > > Obviously, had we known that from the beginning, things would have > > been done differently. However, there was - in hindsight - a lack of > > realisation just how expensive any significant changes would appear > > to vendors. > > And why on earth would the thought of having a threading API > significantly different from the POSIX API even be on the > table? It boggles the mind. 1. Because POSIX threads is known to have weaknesses in its design e.g. signal handling. These BTW have been fixed in C1X and there are some significant departures from the POSIX API wherever pthreads was just plain broke. Some of these departures may - on some platforms - require rejigging the internal kernel/userspace boundary. Before you ask, no I don't know what these are, it isn't my area of expertise. 2. Because pthreads were designed a long time ago in a world where threading was simpler and likely core count was lower. There are more use models now, and originally it was thought that incorporating some elements of newer threading models would be wise. Bear in mind that C1X - unlike POSIX - has to incorporate EVERY kind of computing system thinkable. C1X needs to run - without major baggage - on everything from tiny, OSless systems right up to thousand CPU core highly proprietary systems. And it must do this while staying as backward compatible with legacy systems as possible. 3. Because pthreads is not the only major threading implementation out there. The NT/OS/2 model is hugely popular if fundamentally anti-scalable in design and pthreads don't map exactly one to one with them. For example, thread cancellation is completely missing from C1X as it would require significant kernel rewriting on NT, so it got chopped completely. It had been hoped we could come up with something which worked around the lack of thread cancellation, but we didn't make it in time. It'll be TR1 before we nail the corner cases. Right now, there are quite a few places where under the C1X API the program will just hang if things go wrong and there is no legal way out at all. That is unfortunate, but as always it's a question of resourcing and time. Most people's employers don't see how investing in standards work improves their bottom line, so a lot of the grunt work is goodwill and hobby time. 4. Because POSIX does evolve over time - indeed, its next release is same year as C1X (i.e. next year). People sit on both ISO committees and are on the Austin Working Group. There is significant cross-pollination. The changes in C1X are highly likely to become normalised in the next iteration of POSIX. So think of this way, the departures from POSIX in C1X were mostly intended as departures by POSIX from POSIX next iteration anyway. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 10:09:25 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E3971065672; Tue, 20 Dec 2011 10:09:25 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2D02B8FC19; Tue, 20 Dec 2011 10:09:24 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 08D2A5DB3; Tue, 20 Dec 2011 10:09:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBKA9N3A003066; Tue, 20 Dec 2011 10:09:23 GMT (envelope-from phk@phk.freebsd.dk) To: "Niall Douglas" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Dec 2011 09:48:12 GMT." <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 20 Dec 2011 10:09:23 +0000 Message-ID: <3065.1324375763@critter.freebsd.dk> Cc: threads@freebsd.org, arch@freebsd.org 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 10:09:25 -0000 In message <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com>, "Niall Douglas" writes: >On 19 Dec 2011 at 17:31, Daniel Eischen wrote: > >> > Obviously, had we known that from the beginning, things would have >> > been done differently. However, there was - in hindsight - a lack of >> > realisation just how expensive any significant changes would appear >> > to vendors. >> >> And why on earth would the thought of having a threading API >> significantly different from the POSIX API even be on the >> table? It boggles the mind. > >1. Because [...] Nice and fine. But can you explain, why the job is done so half-assedly ? Why are fundamentally and necessary programming tools, such as a "assert this mutex is held" missing ? 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 ? Where did the ability to control a threads stacksize or other attributes go in thrd_create() ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 12:50:49 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C7D106564A; Tue, 20 Dec 2011 12:50:49 +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 2F5018FC0A; Tue, 20 Dec 2011 12:50:48 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 219519EE70A; Tue, 20 Dec 2011 12:50:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324385448; bh=kGB5UvMmPwKneA7dbch3S3ogl6k5qac4BNFrWGHI4G0=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=kKRQ/xbk2XuqkZukKESlKuJvK+gCmf1PkZJ3ZVJ1SyiQK2cM2PF5WWQCW3sae+ypo I2/8at4y4WAZqgdFs0FdRBWJLVEKfD+jsf6yHGEpQtQD/IJiqqrh9Q+PT5dADGysq+ 4qMty26vHXwT2sOyNpoujQKLTeGPPDniUFyQwaB4= 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 CB61D9EE49B; Tue, 20 Dec 2011 12:50:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324385447; bh=kGB5UvMmPwKneA7dbch3S3ogl6k5qac4BNFrWGHI4G0=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=YfFYTsZdxjAw+WOuoxvdlCvmUgyvAmqM9l5QiwN6xyeZhwXBYnXyYXCX4EkedLanO a4fYXcQz0zEX6x4haBHeWjX23bHM6c9Lq4aYNAuFH8GCoa1Mp4pENdMQqvr4jl2T0b qmN53VD6EfCgC4V2uzkSHhl2FepL+ZQaZ2I+0ZM8= From: "Niall Douglas" To: threads@freebsd.org, arch@freebsd.org Date: Tue, 20 Dec 2011 12:50:48 -0000 MIME-Version: 1.0 Message-ID: <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <3065.1324375763@critter.freebsd.dk> References: >, <3065.1324375763@critter.freebsd.dk> X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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 12:50:50 -0000 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. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 13:05:00 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89588106564A; Tue, 20 Dec 2011 13:05:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 411A28FC13; Tue, 20 Dec 2011 13:04:59 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pBKD4wbN046764; Tue, 20 Dec 2011 08:04:58 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Tue, 20 Dec 2011 08:04:59 -0500 (EST) Date: Tue, 20 Dec 2011 08:04:58 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Niall Douglas In-Reply-To: <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> Message-ID: References: <20111216214913.GA1771@hoeg.nl>, <4EEF9235.31023.B2519C9A@s_sourceforge.nedprod.com>, <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 13:05:00 -0000 On Tue, 20 Dec 2011, Niall Douglas wrote: > 4. Because POSIX does evolve over time - indeed, its next release is > same year as C1X (i.e. next year). People sit on both ISO committees > and are on the Austin Working Group. There is significant > cross-pollination. The changes in C1X are highly likely to become > normalised in the next iteration of POSIX. So think of this way, the > departures from POSIX in C1X were mostly intended as departures by > POSIX from POSIX next iteration anyway. Think what you want, but monitoring the austin mailing list, it seemed to catch everyone by surprise that C1X was coming up with a threading interface that diverged from POSIX. At least a couple of years ago that was the case, but perhaps that prompted the cross-pollination. -- DE From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 13:40:03 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD7A7106566B; Tue, 20 Dec 2011 13:40:03 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 333008FC08; Tue, 20 Dec 2011 13:40:02 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6816B5DA8; Tue, 20 Dec 2011 13:40:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBKDe0FX062148; Tue, 20 Dec 2011 13:40:00 GMT (envelope-from phk@phk.freebsd.dk) To: "Niall Douglas" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Dec 2011 12:50:48 GMT." <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 20 Dec 2011 13:40:00 +0000 Message-ID: <62147.1324388400@critter.freebsd.dk> Cc: threads@freebsd.org, arch@freebsd.org 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 13:40:04 -0000 In message <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com>, "Niall Douglas" writes: >> 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. BS: Show me a working implementation of a mutex where you cannot tell if the current thread holds the mutex when it is locked ? (Hint: add a variable to the mutex, protected by the mutex, storing the thread-id if the locking thread ? Nudge, nudge, wink, wink ?) >> 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. No, actually UTC is much unsafer than the alternative, and in general much less useful and desirable for the same reasons it is unsafe. UTC as implemented on a computer is not a continuous timescale, it is not even an monotonic timescale if you are unlucky. The far too typical scenario is that you boot your system and then some minutes later NTPD will step your clock forwards if you're lucky, and backwards by a day if you're not. >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. And I would expect that most implementations will not even think about that cornercase, and just do stupid things if the UTC time is stepped backwards. (Case in point: The Oracle databases freezing over the leap-second were caused by code that tried to work around broken standards in this particular space) But if this was a well-thought-out standard, instead of a half-assed job, it wouldn't matter what you and I expect: Then the standard would have said what to expect. >None of the timed functions in C11 should ever be used outside a loop >which tests and rewaits if necessary. A loop doesn't help you if the UTC time is stepped back 1 hour and your sleep was supposed to be only one second. > I agree this isn't clear from >the spec, but the spec is not a programming manual. Which only goes to show that the great stride in education which UNIX brought, has been missed widely by the ISO-C crew. How do you expect actual real-life programmers to know how to use this brittle API's, if you don't even give them an example to look at, or write about their major caveats in the spec ? And maybe, in trying to express that using a real-world example, the standards comittee would realize that UTC was a mistake, and changed the timeout argument to a relative time interval instead, like for instance the poll(2) system-call. >> 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 would assume that the people who found it dangerous were morons without any actual real-life experience programming threads on computers with finite resources ? The way POSIX did that is far from a piece of beauty, but at least it provides a way to communicate such attributes. You are welcome to think that everybody in the ISO-C group is better and smarter than me. If they are, this standard doesn't show it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 13:52:25 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 25B231065673; Tue, 20 Dec 2011 13:52:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D71958FC16; Tue, 20 Dec 2011 13:52:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 7394D46B06; Tue, 20 Dec 2011 08:52:24 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F23C1B93E; Tue, 20 Dec 2011 08:52:23 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 20 Dec 2011 08:22:25 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <3065.1324375763@critter.freebsd.dk> <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> In-Reply-To: <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112200822.26369.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 08:52:24 -0500 (EST) Cc: freebsd-threads@freebsd.org 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 13:52:25 -0000 On Tuesday, December 20, 2011 7:50:48 am Niall Douglas wrote: > 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. 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". > > 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. You cannot easily assert that a mutex is held by some other thread; however, if you use a thread-unique identifier as your lock cookie, then you can check to see if the current thread owns a mutex without any races (and this is a _very_ useful debugging technique in real-world applications). 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). For those machines, you may be reduced to having a lock cookie of just 0 or 1 and you cannot distinguish the case of the current thread holding the lock versus another thread holding the lock. (It is hard to safely assert read locks for reader/writer locks for much the same reason as common lock- cookie encodings use a simple count for read locks.) However, that is due to a limitation of your abstract machine's atomic ops, not a race. > > 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. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 14:22:01 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 A2C461065675; Tue, 20 Dec 2011 14:22:01 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5FEF28FC15; Tue, 20 Dec 2011 14:22:01 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id DE65D5E50; Tue, 20 Dec 2011 14:02:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBKE2LVd073234; Tue, 20 Dec 2011 14:02:21 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Dec 2011 08:22:25 EST." <201112200822.26369.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 20 Dec 2011 14:02:21 +0000 Message-ID: <73233.1324389741@critter.freebsd.dk> Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org 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:22:01 -0000 In message <201112200822.26369.jhb@freebsd.org>, John Baldwin writes: >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). There is no way this can be impossible on a platform which can implement a mutex in the first place: mtx_lock(l) { atomic_magic_lock(l->lock_field) l->id = thread_id; } mtx_unlock(l) { assert(l->id == thread_id); l->id = NULL; atomic_magic_unlock(l->lock_field) } mtx_assert_held(l) { assert(l->lock-field != 0); assert(l->id == thread_id); } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 14:34:56 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A478B1065672; 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 5A27A8FC17; Tue, 20 Dec 2011 14:34:56 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id BC6D388C001; 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=CL9mgfJFNZTtTokYarUKRsTn+BkmTtdMN3Bcp6kOBbU=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=xUc/Mi+7nsWCgP/CYpeXhvyZZgXobNo6eegNf/qPmV0NMdCpGa0+mdahPknEAlT8N oOThfOU1EbFWpFHzjBbFsZsjoUfcMpX3BrnkScwc9ws6uf/WywXIurd67JPvLro8MW TQy55CheWSvmkdXe45Mx7Ea7GjJhOyo3JN7i37zw= 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 82D129EE70A; Tue, 20 Dec 2011 14:34:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324391695; bh=CL9mgfJFNZTtTokYarUKRsTn+BkmTtdMN3Bcp6kOBbU=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=xUc/Mi+7nsWCgP/CYpeXhvyZZgXobNo6eegNf/qPmV0NMdCpGa0+mdahPknEAlT8N oOThfOU1EbFWpFHzjBbFsZsjoUfcMpX3BrnkScwc9ws6uf/WywXIurd67JPvLro8MW TQy55CheWSvmkdXe45Mx7Ea7GjJhOyo3JN7i37zw= From: "Niall Douglas" To: threads@freebsd.org, arch@freebsd.org Date: Tue, 20 Dec 2011 14:34:54 -0000 MIME-Version: 1.0 Message-ID: <4EF09D0E.10213.B663FC80@s_sourceforge.nedprod.com> Priority: normal In-reply-to: References: <20111216214913.GA1771@hoeg.nl>, <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com>, X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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:04, Daniel Eischen wrote: > > 4. Because POSIX does evolve over time - indeed, its next release is > > same year as C1X (i.e. next year). People sit on both ISO committees > > and are on the Austin Working Group. There is significant > > cross-pollination. The changes in C1X are highly likely to become > > normalised in the next iteration of POSIX. So think of this way, the > > departures from POSIX in C1X were mostly intended as departures by > > POSIX from POSIX next iteration anyway. > > Think what you want, but monitoring the austin mailing list, > it seemed to catch everyone by surprise that C1X was coming > up with a threading interface that diverged from POSIX. > At least a couple of years ago that was the case, but > perhaps that prompted the cross-pollination. You're absolutely correct - it was exactly this divergence which brought a lot more eyeballs to the C11 draft. And indeed it was about two, two and half years ago now. It's actually amazing how fast time has gone. As with any ISO standard, right at the beginning of a draft there's only a few people working on something. You can get some really radical and/or badly thought through stuff coming in at that stage. As the release date nears, more eyeballs come on board and stuff gets much more conservative. Anything unnecessary, especially given vendor objections to doing anything more than necessary, tends to get excised or in particular in C11 made into an optional module. There's a LOT of optional stuff in C11. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 14:38:36 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9799F106566B; Tue, 20 Dec 2011 14:38:36 +0000 (UTC) (envelope-from BATV+4d3c52616b37ff3928b6+3040+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:4830:2446:ff00:4687:fcff:fea6:5117]) by mx1.freebsd.org (Postfix) with ESMTP id 42AB58FC0A; Tue, 20 Dec 2011 14:38:36 +0000 (UTC) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1Rd0pu-0000pb-3n; Tue, 20 Dec 2011 14:38:34 +0000 Date: Tue, 20 Dec 2011 09:38:34 -0500 From: Christoph Hellwig To: Niall Douglas Message-ID: <20111220143833.GA31812@infradead.org> References: <20111216214913.GA1771@hoeg.nl> <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> <4EF09D0E.10213.B663FC80@s_sourceforge.nedprod.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF09D0E.10213.B663FC80@s_sourceforge.nedprod.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Cc: threads@freebsd.org, arch@freebsd.org 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:38:36 -0000 On Tue, Dec 20, 2011 at 02:34:54PM -0000, Niall Douglas wrote: > excised or in particular in C11 made into an optional module. There's > a LOT of optional stuff in C11. Which is a very big warning light for a bad standard. Hopefull it's not as bad as the T10 standards. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 14:47:35 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C257106564A; Tue, 20 Dec 2011 14:47:35 +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 175EE8FC13; Tue, 20 Dec 2011 14:47:34 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 641329EE475; Tue, 20 Dec 2011 14:47:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324392453; bh=zQ1NjD+skNI/Zx+L69r6YMNznMTLTcZfBobYcklKFJA=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=VQN31HZ4nzeL9ulbV5gZILFeEm+6OzogeOk7R0voF7xKBI2Du2Enp8+QbiVKnG7c9 zmNE3E4muMdGZzng6K3f+UB37fVyufQqpcjUm5MZ1EW17jLYLyH6TKMeju8UgIaXcf AJk99SYsuyc5T9x2EDTVovlTRvPcjdhvUHF7FN2A= 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 67ABC9EE241; Tue, 20 Dec 2011 14:47:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324392444; bh=zQ1NjD+skNI/Zx+L69r6YMNznMTLTcZfBobYcklKFJA=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=gVD0lT/h24dsS7RuLQB9jGh4Q2SwoLIeF95sIe3iE+zUZvGuns7lHnXH709GDLr8p 9j3bElOc4V3SYalrRtIRIwp14PmibS/fvGFzaRHpV2wVPis6rPam59G2spHXaFaH0j t5sStiUMfle5MmmcU+6M/fs5i0akmb3Fs7t3sTu0= From: "Niall Douglas" To: threads@freebsd.org, arch@freebsd.org Date: Tue, 20 Dec 2011 14:47:25 -0000 MIME-Version: 1.0 Message-ID: <4EF09FFD.7768.B66F73ED@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <62147.1324388400@critter.freebsd.dk> References: >, <62147.1324388400@critter.freebsd.dk> X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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:47:35 -0000 On 20 Dec 2011 at 13:40, Poul-Henning Kamp wrote: > >If I remember correctly UTC was seen as the safest of all options > >available. Annoying to program I agree, but definitely safer than > >alternatives. > > No, actually UTC is much unsafer than the alternative, and in general > much less useful and desirable for the same reasons it is unsafe. > > UTC as implemented on a computer is not a continuous timescale, > it is not even an monotonic timescale if you are unlucky. Sure, it even varies slightly between CPU core on some platforms. > And maybe, in trying to express that using a real-world example, > the standards comittee would realize that UTC was a mistake, and > changed the timeout argument to a relative time interval instead, > like for instance the poll(2) system-call. There was some very good argument against relative periods. I honestly can't remember what that was. It was a long time ago. > >> 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 would assume that the people who found it dangerous were morons > without any actual real-life experience programming threads on > computers with finite resources ? I think you are out of order in this public comment and you should apologise to those who have served on WG14. If you disagree with the standard, please feel free to submit an erratum to http://open-std.org/jtc1/sc22/wg14/ Or even better, participate and donate your own time to the committee. They are very inclusive and more than happy to give time to all viewpoints. You don't even need to officially join - you can attend or participate as an observer. Otherwise quite frankly I don't care what your background, your rep or your experience is. Feel free to voice an opinion after you have attended a few ISO committee meetings and seen the work done there. Otherwise you don't know what you're talking about. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 14:52:51 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 4E4F01065678; Tue, 20 Dec 2011 14:52:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 25B6B8FC17; Tue, 20 Dec 2011 14:52:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id CBE2A46B32; Tue, 20 Dec 2011 09:52:50 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5D0E6B955; Tue, 20 Dec 2011 09:52:50 -0500 (EST) From: John Baldwin To: "Poul-Henning Kamp" Date: Tue, 20 Dec 2011 09:43:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <73233.1324389741@critter.freebsd.dk> In-Reply-To: <73233.1324389741@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112200943.18812.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:52:50 -0500 (EST) Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org 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:52:51 -0000 On Tuesday, December 20, 2011 9:02:21 am Poul-Henning Kamp wrote: > In message <201112200822.26369.jhb@freebsd.org>, John Baldwin writes: > > >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). > > There is no way this can be impossible on a platform which can > implement a mutex in the first place: > > > mtx_lock(l) > { > atomic_magic_lock(l->lock_field) > l->id = thread_id; > } > > mtx_unlock(l) > { > assert(l->id == thread_id); > l->id = NULL; > atomic_magic_unlock(l->lock_field) > } > > mtx_assert_held(l) > { > assert(l->lock-field != 0); > assert(l->id == thread_id); > } Yep, having a helper field to track the owner would work fine on such degenerate platforms. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 14:58:24 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A2C41065673; Tue, 20 Dec 2011 14:58:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 468D28FC1C; Tue, 20 Dec 2011 14:58:23 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9C43F5C34; Tue, 20 Dec 2011 14:58:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBKEwM4S078108; Tue, 20 Dec 2011 14:58:22 GMT (envelope-from phk@phk.freebsd.dk) To: "Niall Douglas" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Dec 2011 14:34:54 GMT." <4EF09D0E.10213.B663FC80@s_sourceforge.nedprod.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 20 Dec 2011 14:58:22 +0000 Message-ID: <78107.1324393102@critter.freebsd.dk> Cc: threads@freebsd.org, arch@freebsd.org 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:58:24 -0000 In message <4EF09D0E.10213.B663FC80@s_sourceforge.nedprod.com>, "Niall Douglas" writes: >There's a LOT of optional stuff in C11. And then there are non-optional stuff like , specified so it leaves no doubt, except as to the sanity of the authors. As best I can gather, at one point ISO C decided to use '_' Uppercase Lowercase+digit+'_'* for keywords, and that begat us '_Complex', '_Alignas' (a famous greek poet ?), '_Generic'', and also '_Noreturn'. Then somebody probably pointed out that inline _Noreturn foo(int bar); just looked plain ugly. Then some smart person came up with which shall contain, exactly and only: #define noreturn _Noreturn So that we can write: #include inline noreturn foo(int bar); Now, explain to me, why this was more important, and got included, than being able to say: struct foo_protocol_header { little_endian uint16_t proto_ver @ 0, little_endian uint32_t seq_no @ 4, little_endian uint32_t ack_no @ 10, little_endian uint8_t proto_req @ 16, }; And have the compiler do the error-prone idiot-work for us, no matter which platform or compiler we use ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 15:09:27 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 4A3461065673 for ; Tue, 20 Dec 2011 15:09:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 09BFA8FC14 for ; Tue, 20 Dec 2011 15:09:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 807CF46B0D; Tue, 20 Dec 2011 10:09:26 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 10F98B91A; Tue, 20 Dec 2011 10:09:26 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Date: Tue, 20 Dec 2011 10:09:25 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112200822.26369.jhb@freebsd.org> <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> In-Reply-To: <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201112201009.25534.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 10:09:26 -0500 (EST) Cc: 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 15:09:27 -0000 On Tuesday, December 20, 2011 9:34:54 am Niall Douglas wrote: > On 20 Dec 2011 at 8:22, John Baldwin wrote: >=20 > > > Everything is the way it is for a good reason. If it doesn't make=20 > > > sense to you that's most likely because you're not half as=20 > > > experienced or clever as you think you are. If you really want to=20 > > > know why something is the way it is, all discussion regarding all=20 > > > points is documented in full. > >=20 > > 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". >=20 > That's not what I said John, and I object to you saying that I did. I=20 > said, very specifically, that everything is the way it is for a good=20 > reason. I did not at any stage suggest it was perfect, or right, or=20 > even wise. =46air enough, but I'm not sure I would agree with your definition of "good= "=20 reasons. > > > > Why are fundamentally and necessary programming tools, such as a > > > > "assert this mutex is held" missing ? > > >=20 > > > I think that was rejected due to concerns about introducing race=20 > > > conditions if I remember correctly. You'll generally find there is no= =20 > > > easy way of checking the state of anything threading related for the= =20 > > > same reason. > >=20 > > Err, no, there should be no races here. >=20 > Sorry, I meant race conditions in the way a typical end user=20 > programmer might naively choose to use it. A lot of APIs were dropped=20 > or modified to help inhibit the damage from na=EFve use. Humm. I fail to see how a user can misuse an assert() in a way that creates a race condition. An assert(), by it's nature, should have no program visi= ble changes. If the programmer puts the assertion in the wrong place then it may very well lead to false positives, but that is true of any assertion. I can understand why you may not want users to use the equivalent of an 'islocked' function (I'm not a big fan of those myself), but an assertion is weaker than an 'islocked' function. We could look at adding an _np extension. However, I expect that in practi= ce nothing is going to use this API for a long while (if ever). On POSIX syst= ems pthreads is going to be more portable and there is a lot of code already=20 written to pthreads. > I might add there is absolutely no reason why implementations can't=20 > add _np extensions. The spec might even add them in a later TR if=20 > they prove common enough. For example, I'd like thread_timedjoin() in=20 > there, but I'll have to get Austin to sign off on pthread_timedjoin()=20 > first. I agree this would be a useful extension. What I would actually like in=20 =46reeBSD-land (and I'm not sure if Apple's libdispatch already does this=20 internally) is to be able to add a kevent() for a thread and have it fire w= hen=20 the thread exits. This would be similar to how a thread in NT becomes=20 signalled when it exits. =2D-=20 John Baldwin From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 15:14:25 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A9E106566B; Tue, 20 Dec 2011 15:14:25 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2C35B8FC0A; Tue, 20 Dec 2011 15:14:24 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2A2DF5DAA; Tue, 20 Dec 2011 15:14:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBKFEMcq078247; Tue, 20 Dec 2011 15:14:22 GMT (envelope-from phk@phk.freebsd.dk) To: "Niall Douglas" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Dec 2011 14:47:25 GMT." <4EF09FFD.7768.B66F73ED@s_sourceforge.nedprod.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 20 Dec 2011 15:14:22 +0000 Message-ID: <78246.1324394062@critter.freebsd.dk> Cc: threads@freebsd.org, arch@freebsd.org 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 15:14:25 -0000 In message <4EF09FFD.7768.B66F73ED@s_sourceforge.nedprod.com>, "Niall Douglas" writes: >> And maybe, in trying to express that using a real-world example, >> the standards comittee would realize that UTC was a mistake, and >> changed the timeout argument to a relative time interval instead, >> like for instance the poll(2) system-call. > >There was some very good argument against relative periods. I >honestly can't remember what that was. It was a long time ago. There are no good arguments against relative periods, in particular not when the crap they are replaced with requires you to put a loop around the sleep to get the desired behaviour in the first place. The fact that you cant even remeber the argument doesn't in any way make it any more convincing. >> I would assume that the people who found it dangerous were morons >> without any actual real-life experience programming threads on >> computers with finite resources ? > >I think you are out of order in this public comment and you should >apologise to those who have served on WG14. Fuck if will apologize! I will even repeat and clarify my charge to make sure that it is not misunderstood: WG14 are a pile of morons, who have been steadily ruining the C language with utter and useless crap, while only solving an absolute minority of the actual problems and not in any meaningful way developed the language during their time of custody. >Otherwise quite frankly I don't care what your background, your rep >or your experience is. Feel free to voice an opinion after you have >attended a few ISO committee meetings and seen the work done there. >Otherwise you don't know what you're talking about. I run a one man company which does not allow me to fly around the world to sit in meetings with morons who clearly havn't done any serious programming in far too long time. If I could afford it, and did it, I would undoubtedly in a mere matter of months, be a just as useless moron the current crew. And I know exactly what I'm talking about: A programming language I have been using day in and day out for 28 years. I may not now very much about endless meetings churning useless specifications, that have no relationship with what programmers of real-world software actually need from their programming language. It is not a lack of knowledge I see as a problem. WG14 can go to hell, and the C language would be better of if they did. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 17:19:55 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 39D85106564A; Tue, 20 Dec 2011 17:19:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C57278FC19; Tue, 20 Dec 2011 17:19:54 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pBKGujYV032515; Tue, 20 Dec 2011 11:56:45 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Tue, 20 Dec 2011 11:56:45 -0500 (EST) Date: Tue, 20 Dec 2011 11:56:45 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201112201009.25534.jhb@freebsd.org> Message-ID: References: <201112200822.26369.jhb@freebsd.org> <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> <201112201009.25534.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1324400205=:29118" Cc: freebsd-threads@freebsd.org Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:19:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1324400205=:29118 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Dec 2011, John Baldwin wrote: > On Tuesday, December 20, 2011 9:34:54 am Niall Douglas wrote: > >>>>> 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. > > Humm. I fail to see how a user can misuse an assert() in a way that crea= tes > a race condition. An assert(), by it's nature, should have no program vi= sible > changes. If the programmer puts the assertion in the wrong place then it > may very well lead to false positives, but that is true of any assertion.= I > can understand why you may not want users to use the equivalent of an > 'islocked' function (I'm not a big fan of those myself), but an assertion= is > weaker than an 'islocked' function. > > We could look at adding an _np extension. However, I expect that in prac= tice > nothing is going to use this API for a long while (if ever). On POSIX sy= stems > pthreads is going to be more portable and there is a lot of code already > written to pthreads. And that is exactly the point that Butenhof makes in this comment about the ISO C standard 3 years ago: https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=3Dshow_archive.= tpl&source=3DL&listname=3Daustin-group-l&id=3D11671 His comments are a good read, and are still being echoed in this thread. I wonder how much the final standard changed from the working standard to which his comments pertain... --=20 DE ---559023410-851401618-1324400205=:29118-- From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 19:17:37 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 7946B106566C for ; Tue, 20 Dec 2011 19:17:37 +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 04FD08FC22 for ; Tue, 20 Dec 2011 19:17:37 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 354879EE241; Tue, 20 Dec 2011 19:17:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324408656; bh=7PwCtpKXfe9JICB9QQJoPW3/8FUgHy539JSb5SWRGkQ=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=YVfRAPYmxtO8SFWu0C82vc3qQ4LwzL4BqzmZiJDsHvLZiafsSQsxlP5tKdgh4emhR 5j5+srWXXnv3YU715DnmXkw6T7KLX7o36uWYoRofciWXYrhyFAd9y5EgCkswZrj39l Z1qSm9SNRf4D5oGr8WSnug817gH8nmUl4OmHK7fk= 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 50D749EE241 for ; Tue, 20 Dec 2011 19:17:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324408655; bh=7PwCtpKXfe9JICB9QQJoPW3/8FUgHy539JSb5SWRGkQ=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=ySVSKvghFvQPW6A9b8aTkdu2zOarxA8ESZ/QO92OvVU9zk3EGMBaTogjFpImGVUvK BdUE4OPkAJrhaPXpyFAVwiUjOwG80yvESxncuaSdpTFIjZJkxi0alkmLXvGFReKdsW skG3irf8c6uiUkj+Sr5JCapZKWRAaB0KtUzU10/Q= From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 20 Dec 2011 19:17:36 -0000 MIME-Version: 1.0 Message-ID: <4EF0DF50.12183.B766CEDD@s_sourceforge.nedprod.com> Priority: normal In-reply-to: References: , <201112201009.25534.jhb@freebsd.org>, X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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 19:17:37 -0000 On 20 Dec 2011 at 11:56, Daniel Eischen wrote: > > We could look at adding an _np extension. However, I expect that in practice > > nothing is going to use this API for a long while (if ever). On POSIX systems > > pthreads is going to be more portable and there is a lot of code already > > written to pthreads. > > And that is exactly the point that Butenhof makes in this comment > about the ISO C standard 3 years ago: > > https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=11671 > > His comments are a good read, and are still being echoed > in this thread. > > I wonder how much the final standard changed from the working > standard to which his comments pertain... I can tell you there was a flurry of activity about six months ago fixing things like using struct timespec which I was very glad about. And certainly the deviances from POSIX in the final spec are minimal compared to what they were. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 19:17:38 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 83411106564A for ; Tue, 20 Dec 2011 19:17:38 +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 34FB48FC14 for ; Tue, 20 Dec 2011 19:17:38 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 68BDD9EE49B; Tue, 20 Dec 2011 19:17:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324408657; bh=e94oREPl8qbQZsc/+GliX5nnlc1IpSshZvm5uhmvUN8=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=g3VEr7lqA4cblbNYBLLErt7wg/YQkPbbcj8sMoiWUQNR2yxyWAOKnJDoInmUpUw5X ph7btmN8xqcnrvtDpLCl3OT39NkQ0Mfrd9x+LcAYDODf/WnJ3+xQot6U/4jLfQQlda Wz5v6vMQnTaGz+WuH1W8/DVLdeIwgPlALwPzzMVc= 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 DAEBD9EE476 for ; Tue, 20 Dec 2011 19:17:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324408656; bh=e94oREPl8qbQZsc/+GliX5nnlc1IpSshZvm5uhmvUN8=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=ukWYlNjWNc7FnJrct6ec80hCqr4snPZIY7il3TKZPnAtMfBHYC/YpTZ30DPlWJG/9 JwuvBlim42MfebRyY/uFMq8ic7epN8hKdKIRORsZhSf3qt8QejH0job4ICMNBLPXGz COF5ceezbeq5baB1GXzIfwQtmOYprvk2TyW1xCnc= From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 20 Dec 2011 19:17:36 -0000 MIME-Version: 1.0 Message-ID: <4EF0DF50.9243.B766CF98@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <201112201009.25534.jhb@freebsd.org> References: , <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com>, <201112201009.25534.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 19:17:38 -0000 On 20 Dec 2011 at 10:09, John Baldwin wrote: > > 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. > > Fair enough, but I'm not sure I would agree with your definition of "goo= d" > reasons. Maybe it's a difference in US vs UK English :). By "good" I equally mean "sound" or "valid". > > 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. > > Humm. I fail to see how a user can misuse an assert() in a way that cre= ates > a race condition. An assert(), by it's nature, should have no program v= isible > changes. If the programmer puts the assertion in the wrong place then i= t > may very well lead to false positives, but that is true of any assertion= . I > can understand why you may not want users to use the equivalent of an > 'islocked' function (I'm not a big fan of those myself), but an assertio= n is > weaker than an 'islocked' function. My statements come from my (prolonged) efforts to develop a safe permit threading object for C11 as people have the tendency to roll their own buggy implementations which just don't work right. This was based on the Java permit primitive, but because C has function pointers it is more flexible. You can see the last public version of this at https://github.com/ned14/C1Xstuff/tree/ISO_TS_pre/N1572. BTW, it needs splitting into two implementations, one for single releaser and the other for multi releaser. During the very drawn out process of consulting with everyone who has a stake in this, I probably talked to almost everyone who contributed to the threading libraries of C (and indeed C++). The fact they repeatedly beat my design and implementation into pieces was immensely frustrating but in hindsight they were right. As much as it's design by committee, there is one hell of a lot of talent in that pool. > We could look at adding an _np extension. However, I expect that in pra= ctice > nothing is going to use this API for a long while (if ever). On POSIX s= ystems > pthreads is going to be more portable and there is a lot of code already= > written to pthreads. What's supposed to happen is that the C++ threading layer is going to be implemented using the C threading layer - hence the need for feature parity. I would imagine that will expose a whole load of issues not previously thought through. It certainly ought to be first test of the C API in anger anyway. I think for new code written to run across systems the new API will be very useful. Not everything runs POSIX after all. Even with its warts that will drive adoption. > > 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. > > I agree this would be a useful extension. I would personally call it vital in C11, because thread_join() is one of the very few places a process can deadlock because there is no timed variant. You can avoid pthread_timedjoin() because you have thread cancellation, but without cancellation thread_join() leaves you no option for catching deadlock at all. This is fatal in C11 and it needs to be fixed urgently. Usefully all major POSIX implementations (including BSD) already implement pthread_timedjoin_np(). I just need to get around to kicking the ball rolling in the Austin WG. > What I would actually like in > FreeBSD-land (and I'm not sure if Apple's libdispatch already does this > internally) is to be able to add a kevent() for a thread and have it fir= e when > the thread exits. This would be similar to how a thread in NT becomes > signalled when it exits. Oh my and you are on the same page ... my proposals for standardising kernel queues got completely shat all over. I also wanted a standard API for reading the local process memory map rather than relying on reading from /proc and another such that a piece of calling code can discover which shared object it is currently executing from (this is very useful for binding translations to that which uses them). All sadly binned due to lack of established practice. I also want a batch API for all calls where this makes sense :). It would be real nice if you could batch stat() and batch malloc() etc. But that'll be long down the line I'd say. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 22:26:19 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 12CFE106564A for ; Tue, 20 Dec 2011 22:26:19 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id A12528FC12 for ; Tue, 20 Dec 2011 22:26:18 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 0639F359311 for ; Tue, 20 Dec 2011 23:26:18 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id E204028468; Tue, 20 Dec 2011 23:26:17 +0100 (CET) Date: Tue, 20 Dec 2011 23:26:17 +0100 From: Jilles Tjoelker To: freebsd-threads@freebsd.org Message-ID: <20111220222617.GC75886@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [patch] Fix unchecked atomic_cmpset when unlocking mutex 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 22:26:19 -0000 When unlocking a contested mutex that is not PI or PP, the mutex is made available for new lockers faster by unlocking it in userland and only calling the kernel to wake sleeping threads. This seems to make sense. Although the atomic_cmpset here should never fail because this thread owns the mutex and other threads may only set UMUTEX_CONTESTED which is already set, it seems prudent anyway to check for this. If the atomic_cmpset fails, use the slow path that unlocks in the kernel. Index: lib/libthr/thread/thr_umtx.c =================================================================== --- lib/libthr/thread/thr_umtx.c (revision 228504) +++ lib/libthr/thread/thr_umtx.c (working copy) @@ -154,10 +154,9 @@ { #ifndef __ia64__ /* XXX this logic has a race-condition on ia64. */ - if ((mtx->m_flags & (UMUTEX_PRIO_PROTECT | UMUTEX_PRIO_INHERIT)) == 0) { - atomic_cmpset_rel_32(&mtx->m_owner, id | UMUTEX_CONTESTED, UMUTEX_CONTESTED); + if ((mtx->m_flags & (UMUTEX_PRIO_PROTECT | UMUTEX_PRIO_INHERIT)) == 0 && + atomic_cmpset_rel_32(&mtx->m_owner, id | UMUTEX_CONTESTED, UMUTEX_CONTESTED)) return _umtx_op_err(mtx, UMTX_OP_MUTEX_WAKE, 0, 0, 0); - } #endif /* __ia64__ */ return _umtx_op_err(mtx, UMTX_OP_MUTEX_UNLOCK, 0, 0, 0); } -- Jilles Tjoelker From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 22:28:38 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30383106566C; Tue, 20 Dec 2011 22:28:38 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C005E8FC12; Tue, 20 Dec 2011 22:28:37 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2831:a229:70d2:ba0b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D225B4AC1C; Wed, 21 Dec 2011 02:28:35 +0400 (MSK) Date: Wed, 21 Dec 2011 02:28:32 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <549165194.20111221022832@serebryakov.spb.ru> To: "Niall Douglas" In-Reply-To: <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> References: >, <3065.1324375763@critter.freebsd.dk> <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: threads@freebsd.org, arch@freebsd.org 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 22:28:38 -0000 Hello, Niall. You wrote 20 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 16:50:48: > I would assume that they were considered non portable due to vendor > objection. In particular, I remember an argument that thread=20 > stacksize settings are dangerous and must be omitted. Ouch. So, same stack sizes for programs with 10 and 10'000 threads (on one platform)?! OMG. It is completely unusable, according to my experience with massively-parallel programs (think: programs which could completely load SunFire 15K, 144-way, monster with I/O bound load without any significant lock contention!). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 15:05:25 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12122106566B; Wed, 21 Dec 2011 15:05:25 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C90798FC19; Wed, 21 Dec 2011 15:05:24 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 51C8D6A0B; Wed, 21 Dec 2011 15:05:20 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D6F1580C6; Wed, 21 Dec 2011 16:05:19 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Niall Douglas" References: <85477.1324155737@critter.freebsd.dk> <86ty4y4rj5.fsf@ds4.des.no> <4EEF9235.252.B2519BEE@s_sourceforge.nedprod.com> Date: Wed, 21 Dec 2011 16:05:19 +0100 In-Reply-To: <4EEF9235.252.B2519BEE@s_sourceforge.nedprod.com> (Niall Douglas's message of "Mon, 19 Dec 2011 19:36:21 -0000") Message-ID: <86d3bit174.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, threads@freebsd.org 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: Wed, 21 Dec 2011 15:05:25 -0000 "Niall Douglas" writes: > BTW we entirely expect the C1X threading API to supplant all others,=20 > including POSIX whose threading support will be mostly for backwards=20 > compatibility and may even become deprecated. What do they put in the water at WG14 meetings? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 15:17:05 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE0E106566B; Wed, 21 Dec 2011 15:17:05 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 22B1F8FC0C; Wed, 21 Dec 2011 15:17:05 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id F3E276A17; Wed, 21 Dec 2011 15:16:58 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B1A6980C9; Wed, 21 Dec 2011 16:16:58 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "O. Hartmann" References: <58923.1324292241@critter.freebsd.dk> <4EEF765D.4090300@zedat.fu-berlin.de> Date: Wed, 21 Dec 2011 16:16:58 +0100 In-Reply-To: <4EEF765D.4090300@zedat.fu-berlin.de> (O. Hartmann's message of "Mon, 19 Dec 2011 18:37:33 +0100") Message-ID: <868vm6t0np.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: threads@freebsd.org, Poul-Henning Kamp , Warner Losh , freebsd-arch@freebsd.org 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: Wed, 21 Dec 2011 15:17:05 -0000 "O. Hartmann" writes: > How is the other BSD sibbling, NetBSD, dealing with such things? NetBSD > is supposed to run on a trmendous variety of hardware, even a mixture of > bigendian and littleenddian and I'm quite sure they must have overcome > this probleme anyway. The same way FreeBSD does: where ordering matters, use explicit conversions when reading and writing. The conversion functions / macros are defined in such a manner that unnecessary conversions (e.g. host to little-endian on a little-endian system) do not generate any code at all. The only downside is that you can't directly compare variables unless you're certain that they're both in host order. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 15:23:57 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 B9AE21065676 for ; Wed, 21 Dec 2011 15:23:57 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7841B8FC12 for ; Wed, 21 Dec 2011 15:23:57 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 649D86A00; Wed, 21 Dec 2011 14:59:00 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A104E80C1; Wed, 21 Dec 2011 15:58:57 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Poul-Henning Kamp" References: <73233.1324389741@critter.freebsd.dk> Date: Wed, 21 Dec 2011 15:58:57 +0100 In-Reply-To: <73233.1324389741@critter.freebsd.dk> (Poul-Henning Kamp's message of "Tue, 20 Dec 2011 14:02:21 +0000") Message-ID: <86hb0ut1hq.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-threads@freebsd.org 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: Wed, 21 Dec 2011 15:23:57 -0000 "Poul-Henning Kamp" writes: > There is no way this can be impossible on a platform which can > implement a mutex in the first place: > > > mtx_lock(l) > { > atomic_magic_lock(l->lock_field) > l->id =3D thread_id; > } OK > mtx_unlock(l) > { > assert(l->id =3D=3D thread_id); > l->id =3D NULL; > atomic_magic_unlock(l->lock_field) > } susceptible to race conditions > mtx_assert_held(l) > { > assert(l->lock-field !=3D 0); > assert(l->id =3D=3D thread_id); > } susceptible to race conditions The canonical solution is to use some low-level lock primitive (worst case, a critical section) to protect the mutex structure, but then you need some way for mtx_lock() to sleep if the mutex is held and some way for mtx_unlock() to wake sleepers. You also need to lock the mutex structure in mtx_assert_held(), unless l->id is atomic. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 15:28:28 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 6203F106564A; Wed, 21 Dec 2011 15:28:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB858FC0A; Wed, 21 Dec 2011 15:28:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id AE7A446B09; Wed, 21 Dec 2011 10:28:27 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3513AB93A; Wed, 21 Dec 2011 10:28:27 -0500 (EST) From: John Baldwin To: "Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?=" Date: Wed, 21 Dec 2011 10:28:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <73233.1324389741@critter.freebsd.dk> <86hb0ut1hq.fsf@ds4.des.no> In-Reply-To: <86hb0ut1hq.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201112211028.26780.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Dec 2011 10:28:27 -0500 (EST) Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org, freebsd-threads@freebsd.org 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: Wed, 21 Dec 2011 15:28:28 -0000 On Wednesday, December 21, 2011 9:58:57 am Dag-Erling Sm=C3=B8rgrav wrote: > "Poul-Henning Kamp" writes: > > There is no way this can be impossible on a platform which can > > implement a mutex in the first place: > > > > > > mtx_lock(l) > > { > > atomic_magic_lock(l->lock_field) > > l->id =3D thread_id; > > } >=20 > OK >=20 > > mtx_unlock(l) > > { > > assert(l->id =3D=3D thread_id); > > l->id =3D NULL; > > atomic_magic_unlock(l->lock_field) > > } >=20 > susceptible to race conditions How so? Assume that atomic_magic_unlock() uses a release barrier on the store to l->lock_field such that the write to l->id will post to all CPUs before the write to l->lock_field. > > mtx_assert_held(l) > > { > > assert(l->lock-field !=3D 0); > > assert(l->id =3D=3D thread_id); > > } >=20 > susceptible to race conditions How so? While the current thread holds the lock, it is always coherent with the lock's state (it can't read "stale" values because it is the last thread to write to the lock, and if the thread migrates to another CPU, the mechanics of migrating to another CPU will use sufficient barriers that the new CPU will see all the writes done by this thread). Given that, if you hold the lock, the assertions will never fail while the current thread holds the lock. Similarly, the current thread will always see at least the newest values it wrote to the lock (it may also possibly see writes by another thread/CPU to the lock since it last wrote to the lock, but these are not guaranteed). However, that is sufficient to ensure that least one of the above assertions will fail if the current thread does not hold the lock. Recall that the last tokens it writes to the lock when it releases the lock is to clear both the lock_field and id fields. After such writes, mtx_assert_held() will fail. If another thread acquires the lock and the CPU only sees the first write to lock_field, then the first assertion will not trip, but the second one will (the thread will never see the old value where it thinks 'l->id' is itself as it is guaranteed to see a value that is at least as new as it's last write (which set it to NULL), and no other thread is going to set 'l->id' to this thread's ID). Keep in mind, all that you have to guarantee for an assertion of this type is that the observed state will match the 'locked by current thread' state when the mutex is locked and will look like something else when the mutex isn't locked by this thread. The observed state can be stale, but the assertion will still work correctly as it does not depend on the specific details of the non-owned state, merely that it is not equal to the locked staet. We use this same practice to use non-atomic ops on the mtx_recursed field in our in-kernel mutex implementation as well as it is altered only=20 while the main lock field is locked by the current thread. > The canonical solution is to use some low-level lock primitive (worst > case, a critical section) to protect the mutex structure, but then you > need some way for mtx_lock() to sleep if the mutex is held and some way > for mtx_unlock() to wake sleepers. You also need to lock the mutex > structure in mtx_assert_held(), unless l->id is atomic. l->id is not required to be atomic I believe, but it is not hard to make that true. On many platforms pointers do fit in a word and thus their loads and stores are atomic. You could also use a cookie for the thread id that is an atomic type if your pointers are not atomic (just assign a unique integer id to each thread on thread creation, etc.). =2D-=20 John Baldwin From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 16:02:41 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 796C6106564A for ; Wed, 21 Dec 2011 16:02:41 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED688FC16 for ; Wed, 21 Dec 2011 16:02:41 +0000 (UTC) Received: by dakp5 with SMTP id p5so7132044dak.13 for ; Wed, 21 Dec 2011 08:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=On8O59LF/I7JcHFVHQ9ZNJdUybzJch9in9TtjoMED8U=; b=exU3x1+Lm8hqUcqiTT6n1j3uuKBl6+w9NpsFcqoA22rZ+R6Ea1QLdo3m7Q3i+aCwpr P20Wn95PiMfiFCHCEwy7fHzwOVZixLfbYHdfZcYjS69fXvszEUSk6tm5X1gg+ffPAl7W nInm9v4sbzmPT/U1CEI+iYgddZOtI4DVRAtjs= MIME-Version: 1.0 Received: by 10.68.189.97 with SMTP id gh1mr13880346pbc.37.1324481854813; Wed, 21 Dec 2011 07:37:34 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.55.136 with HTTP; Wed, 21 Dec 2011 07:37:34 -0800 (PST) In-Reply-To: <201112211028.26780.jhb@freebsd.org> References: <73233.1324389741@critter.freebsd.dk> <86hb0ut1hq.fsf@ds4.des.no> <201112211028.26780.jhb@freebsd.org> Date: Wed, 21 Dec 2011 07:37:34 -0800 X-Google-Sender-Auth: GJuA8akkMrwJqeD3Q4-3Y3HKrdI Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , Poul-Henning Kamp , freebsd-threads@freebsd.org, freebsd-arch@freebsd.org 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: Wed, 21 Dec 2011 16:02:41 -0000 2011/12/21 John Baldwin : > On Wednesday, December 21, 2011 9:58:57 am Dag-Erling Sm=F8rgrav wrote: >> "Poul-Henning Kamp" writes: >> > There is no way this can be impossible on a platform which can >> > implement a mutex in the first place: >> > >> > >> > =A0 =A0 mtx_lock(l) >> > =A0 =A0 { >> > =A0 =A0 =A0 =A0 =A0 =A0 atomic_magic_lock(l->lock_field) >> > =A0 =A0 =A0 =A0 =A0 =A0 l->id =3D thread_id; >> > =A0 =A0 } >> >> OK >> >> > =A0 =A0 mtx_unlock(l) >> > =A0 =A0 { >> > =A0 =A0 =A0 =A0 =A0 =A0 assert(l->id =3D=3D thread_id); >> > =A0 =A0 =A0 =A0 =A0 =A0 l->id =3D NULL; >> > =A0 =A0 =A0 =A0 =A0 =A0 atomic_magic_unlock(l->lock_field) >> > =A0 =A0 } >> >> susceptible to race conditions > > How so? =A0Assume that atomic_magic_unlock() uses a release barrier on > the store to l->lock_field such that the write to l->id will post to > all CPUs before the write to l->lock_field. ... which it has to do if the mutex is to do anything useful. Having started on PPC assembly, the concept of 'acquire' and 'release' semantics still make no sense to me. On PPC, the mutex code must issue a sync before clearing the lock word, to guarantee all stores performed before the lock is released are visible before any CPU can see the lock is free. I assume that's the same thing as 'release' semantics. If this isn't done then a CPU can read a value 'protected' by the mutex and get wrong information, rendering the mutex non-functional for memory protection but still function to (for some reason) have only one thread executing a given section of code at a time. If this isn't possible on the hardware (i.e. no memory barrier instructions) then the hardware cannot implement a mutex with useful semantics at all. But note that one of PHK's complaints was that the threaded memory model isn't well specified... Cheers, matthew >> > =A0 =A0 mtx_assert_held(l) >> > =A0 =A0 { >> > =A0 =A0 =A0 =A0 =A0 =A0 assert(l->lock-field !=3D 0); >> > =A0 =A0 =A0 =A0 =A0 =A0 assert(l->id =3D=3D thread_id); >> > =A0 =A0 } >> >> susceptible to race conditions > > How so? =A0While the current thread holds the lock, it is always coherent > with the lock's state (it can't read "stale" values because it is the > last thread to write to the lock, and if the thread migrates to another > CPU, the mechanics of migrating to another CPU will use sufficient > barriers that the new CPU will see all the writes done by this thread). > Given that, if you hold the lock, the assertions will never fail while > the current thread holds the lock. =A0Similarly, the current thread will > always see at least the newest values it wrote to the lock (it may also > possibly see writes by another thread/CPU to the lock since it last > wrote to the lock, but these are not guaranteed). =A0However, that is > sufficient to ensure that least one of the above assertions will fail if > the current thread does not hold the lock. =A0Recall that the last tokens > it writes to the lock when it releases the lock is to clear both the > lock_field and id fields. =A0 After such writes, mtx_assert_held() will > fail. =A0If another thread acquires the lock and the CPU only sees the > first write to lock_field, then the first assertion will not trip, but > the second one will (the thread will never see the old value where it > thinks 'l->id' is itself as it is guaranteed to see a value that is at > least as new as it's last write (which set it to NULL), and no other > thread is going to set 'l->id' to this thread's ID). > > Keep in mind, all that you have to guarantee for an assertion of this > type is that the observed state will match the 'locked by current thread' > state when the mutex is locked and will look like something else when the > mutex isn't locked by this thread. =A0The observed state can be stale, bu= t > the assertion will still work correctly as it does not depend on the > specific details of the non-owned state, merely that it is not equal to > the locked staet. > > We use this same practice to use non-atomic ops on the mtx_recursed > field in our in-kernel mutex implementation as well as it is altered only > while the main lock field is locked by the current thread. > >> The canonical solution is to use some low-level lock primitive (worst >> case, a critical section) to protect the mutex structure, but then you >> need some way for mtx_lock() to sleep if the mutex is held and some way >> for mtx_unlock() to wake sleepers. =A0You also need to lock the mutex >> structure in mtx_assert_held(), unless l->id is atomic. > > l->id is not required to be atomic I believe, but it is not hard to make > that true. =A0On many platforms pointers do fit in a word and thus their > loads and stores are atomic. =A0You could also use a cookie for the threa= d > id that is an atomic type if your pointers are not atomic (just assign a > unique integer id to each thread on thread creation, etc.). > > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 17:27:43 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08CA106566C; Wed, 21 Dec 2011 17:27:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AC10D8FC13; Wed, 21 Dec 2011 17:27:43 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBLHN2ST079514 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 21 Dec 2011 10:23:05 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <78246.1324394062@critter.freebsd.dk> Date: Wed, 21 Dec 2011 10:22:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> References: <78246.1324394062@critter.freebsd.dk> To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 21 Dec 2011 10:23:06 -0700 (MST) Cc: threads@freebsd.org, arch@freebsd.org 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: Wed, 21 Dec 2011 17:27:44 -0000 On Dec 20, 2011, at 8:14 AM, Poul-Henning Kamp wrote: > In message <4EF09FFD.7768.B66F73ED@s_sourceforge.nedprod.com>, "Niall = Douglas"=20 > writes: >=20 >>> And maybe, in trying to express that using a real-world example, >>> the standards comittee would realize that UTC was a mistake, and >>> changed the timeout argument to a relative time interval instead, >>> like for instance the poll(2) system-call. >>=20 >> There was some very good argument against relative periods. I=20 >> honestly can't remember what that was. It was a long time ago. >=20 > There are no good arguments against relative periods, in particular > not when the crap they are replaced with requires you to put a > loop around the sleep to get the desired behaviour in the first > place. >=20 > The fact that you cant even remeber the argument doesn't in any way > make it any more convincing. When time changes in the system, as it is wont to do occasionally, then = absolute time arguments will screw you. There's no way to get them = right that isn't a massively horrible kludge. Let's say you want to = sleep for no more than 1s. You get the time, add 1s to it, get = preempted, ntpd or somebody else notices the clocks are 1 year fast and = adjusts, you get a quatum again and make the call with a timeout now = 1-year in the future. What could possibly outweigh that negative? Warner From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 17:36:44 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B95C106566C; Wed, 21 Dec 2011 17:36:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 564EB8FC18; Wed, 21 Dec 2011 17:36:44 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBLHXN7D079556 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 21 Dec 2011 10:33:25 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> Date: Wed, 21 Dec 2011 10:33:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: >, <3065.1324375763@critter.freebsd.dk> <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> To: "Niall Douglas" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 21 Dec 2011 10:33:26 -0700 (MST) Cc: threads@freebsd.org, arch@freebsd.org 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: Wed, 21 Dec 2011 17:36:44 -0000 On Dec 20, 2011, at 5:50 AM, Niall Douglas wrote: > The job was NOT done half-arsed. If you had any experience of sitting=20= > on these committees you would know how much dedication and effort is=20= > put into standards, especially JTC1 SC22 subcommittees. Every single=20= > API in there has been studied and pored over at length across=20 > multiple years. >=20 > Everything is the way it is for a good reason. If it doesn't make=20 > sense to you that's most likely because you're not half as=20 > experienced or clever as you think you are. If you really want to=20 > know why something is the way it is, all discussion regarding all=20 > points is documented in full. Incredible claims require incredible proof. The APIs speak for = themselves: they are half-assed (and the wrong half in some cases). To = assert that they are somehow clever and we're stupid requires that one = walk through the cleverness. The participants in this thread likely = have a combined century of implementation experience with threads. Perhaps you can point us to the archives where all this discussion is = available? Warner From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 17:47:18 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0580106564A; Wed, 21 Dec 2011 17:47:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6E58FC12; Wed, 21 Dec 2011 17:47:18 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBLHfcO9079629 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 21 Dec 2011 10:41:40 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <868vm6t0np.fsf@ds4.des.no> Date: Wed, 21 Dec 2011 10:41:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3ECEEFA0-6542-46CE-86D5-8A4D8226C81D@bsdimp.com> References: <58923.1324292241@critter.freebsd.dk> <4EEF765D.4090300@zedat.fu-berlin.de> <868vm6t0np.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 21 Dec 2011 10:41:41 -0700 (MST) Cc: threads@freebsd.org, Poul-Henning Kamp , freebsd-arch@freebsd.org 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: Wed, 21 Dec 2011 17:47:18 -0000 On Dec 21, 2011, at 8:16 AM, Dag-Erling Sm=F8rgrav wrote: > "O. Hartmann" writes: >> How is the other BSD sibbling, NetBSD, dealing with such things? = NetBSD >> is supposed to run on a trmendous variety of hardware, even a mixture = of >> bigendian and littleenddian and I'm quite sure they must have = overcome >> this probleme anyway. >=20 > The same way FreeBSD does: where ordering matters, use explicit > conversions when reading and writing. The conversion functions / = macros > are defined in such a manner that unnecessary conversions (e.g. host = to > little-endian on a little-endian system) do not generate any code at > all. The only downside is that you can't directly compare variables > unless you're certain that they're both in host order. And it is difficult for automated tools to help you know if you are = "sure" or not. Warner From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 18:07:12 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07129106566C; Wed, 21 Dec 2011 18:07:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2338B8FC13; Wed, 21 Dec 2011 18:07:10 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 53409308; Wed, 21 Dec 2011 18:57:06 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Wed, 21 Dec 2011 18:54:40 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112211854.40798.hselasky@c2i.net> Cc: threads@freebsd.org, Warner Losh , arch@freebsd.org 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: Wed, 21 Dec 2011 18:07:12 -0000 On Wednesday 21 December 2011 18:33:16 Warner Losh wrote: > On Dec 20, 2011, at 5:50 AM, Niall Douglas wrote: > > 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. > > Incredible claims require incredible proof. The APIs speak for themselves: > they are half-assed (and the wrong half in some cases). To assert that > they are somehow clever and we're stupid requires that one walk through > the cleverness. The participants in this thread likely have a combined > century of implementation experience with threads. > > Perhaps you can point us to the archives where all this discussion is > available? > Hi, Absolute timeouts is no good idea! We should stick with kernel-ticks when possible :-) --HPS From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 18:46:28 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 DB0251065670 for ; Wed, 21 Dec 2011 18:46:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B33288FC0C for ; Wed, 21 Dec 2011 18:46:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6B7D346B0D; Wed, 21 Dec 2011 13:46:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F33E3B95C; Wed, 21 Dec 2011 13:46:27 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Date: Wed, 21 Dec 2011 13:44:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111220222617.GC75886@stack.nl> In-Reply-To: <20111220222617.GC75886@stack.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112211344.51792.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Dec 2011 13:46:28 -0500 (EST) Cc: Subject: Re: [patch] Fix unchecked atomic_cmpset when unlocking mutex 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: Wed, 21 Dec 2011 18:46:28 -0000 On Tuesday, December 20, 2011 5:26:17 pm Jilles Tjoelker wrote: > When unlocking a contested mutex that is not PI or PP, the mutex is made > available for new lockers faster by unlocking it in userland and only > calling the kernel to wake sleeping threads. This seems to make sense. > > Although the atomic_cmpset here should never fail because this thread > owns the mutex and other threads may only set UMUTEX_CONTESTED which is > already set, it seems prudent anyway to check for this. > > If the atomic_cmpset fails, use the slow path that unlocks in the > kernel. > > Index: lib/libthr/thread/thr_umtx.c > =================================================================== > --- lib/libthr/thread/thr_umtx.c (revision 228504) > +++ lib/libthr/thread/thr_umtx.c (working copy) > @@ -154,10 +154,9 @@ > { > #ifndef __ia64__ > /* XXX this logic has a race-condition on ia64. */ > - if ((mtx->m_flags & (UMUTEX_PRIO_PROTECT | UMUTEX_PRIO_INHERIT)) == 0) { > - atomic_cmpset_rel_32(&mtx->m_owner, id | UMUTEX_CONTESTED, UMUTEX_CONTESTED); > + if ((mtx->m_flags & (UMUTEX_PRIO_PROTECT | UMUTEX_PRIO_INHERIT)) == 0 && > + atomic_cmpset_rel_32(&mtx->m_owner, id | UMUTEX_CONTESTED, UMUTEX_CONTESTED)) > return _umtx_op_err(mtx, UMTX_OP_MUTEX_WAKE, 0, 0, 0); > - } > #endif /* __ia64__ */ > return _umtx_op_err(mtx, UMTX_OP_MUTEX_UNLOCK, 0, 0, 0); > } Not checking for a failing atomic_cmpset seems inherently broken to me. When I first saw this, I wondered if fixing this would fix the "race" on ia64. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 19:10:10 2011 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 442101065680 for ; Wed, 21 Dec 2011 19:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC028FC1B for ; Wed, 21 Dec 2011 19:10:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBLJAAJm009817 for ; Wed, 21 Dec 2011 19:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBLJA91e009816; Wed, 21 Dec 2011 19:10:09 GMT (envelope-from gnats) Resent-Date: Wed, 21 Dec 2011 19:10:09 GMT Resent-Message-Id: <201112211910.pBLJA91e009816@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Steven Wills Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9950310656DC for ; Wed, 21 Dec 2011 19:00:29 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 418BB8FC16 for ; Wed, 21 Dec 2011 19:00:13 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pBLJ0D6n034357 for ; Wed, 21 Dec 2011 19:00:13 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id pBLJ0Cr0034356; Wed, 21 Dec 2011 19:00:12 GMT (envelope-from nobody) Message-Id: <201112211900.pBLJ0Cr0034356@red.freebsd.org> Date: Wed, 21 Dec 2011 19:00:12 GMT From: Steven Wills To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/163512: libc defaults to single threaded 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: Wed, 21 Dec 2011 19:10:10 -0000 >Number: 163512 >Category: threads >Synopsis: libc defaults to single threaded >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Dec 21 19:10:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Steven Wills >Release: >Organization: >Environment: >Description: 1) libc defaults to being single-threaded 2) thus apps not linked against libthr don't initialize the structures that threading depends on 3) this causes bugs when said app loads a library that loads libthr 4) said library will take the threaded code path and reference uninitialized data structures An example of this can be seen by removing ports/devel/p5-Glib2/files/patch-threadstest then after building, run "make test" from work/Glib-1.241. Perl will hang in state umtxn. I believe this may also be the source of an intermittent hang in automoc4 (also stuck in state umtxn) seen while building x11/kde4. This was discussed here: http://mail.kde.org/pipermail/kde-freebsd/2011-November/012211.html https://bugs.kde.org/show_bug.cgi?id=276461 >How-To-Repeat: 1. update ports tree 2. Ensure perl is not build with threads (currently not building with threads is the default) 2. cd /usr/ports/devel/p5-Glib2 3. rm files/patch-threadstest 4. make 5. cd work/Glib-1.241 6. make test 7. Verify perl is hung trying to run t/9.t >Fix: I'm told merging libthr into libc may help, but I'm not really sure. No ideas beyond that. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 19:28:59 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 EB7C9106566C for ; Wed, 21 Dec 2011 19:28:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A21338FC18 for ; Wed, 21 Dec 2011 19:28:59 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pBLJSwCc003062; Wed, 21 Dec 2011 14:28:58 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Wed, 21 Dec 2011 14:28:58 -0500 (EST) Date: Wed, 21 Dec 2011 14:28:58 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steven Wills In-Reply-To: <201112211900.pBLJ0Cr0034356@red.freebsd.org> Message-ID: References: <201112211900.pBLJ0Cr0034356@red.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/163512: libc defaults to single threaded X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 19:29:00 -0000 >> Description: > 1) libc defaults to being single-threaded > 2) thus apps not linked against libthr don't initialize the structures that threading depends on > 3) this causes bugs when said app loads a library that loads libthr > 4) said library will take the threaded code path and reference uninitialized data structures > > An example of this can be seen by removing ports/devel/p5-Glib2/files/patch-threadstest then after building, run "make test" from work/Glib-1.241. Perl will hang in state umtxn. > > I believe this may also be the source of an intermittent hang in automoc4 (also stuck in state umtxn) seen while building x11/kde4. This was discussed here: > > http://mail.kde.org/pipermail/kde-freebsd/2011-November/012211.html > https://bugs.kde.org/show_bug.cgi?id=276461 This has always been the case. If an application is going to be linked to a library that requires threads, then that application has to link to libpthread. Applications should be built knowing whether libpthread will be required or not. Either that, or the library should be built to detect whether threading is present and only use thrading features when threading is present (see how libgcc does this as example). The former or latter depends on the what the library is trying to provide. If it needs to spawn threads to accomplish its job, then the former (application needs to link with libpthread). If the library just needs synchronization primitives to protect against a threaded application, then you can use the latter. If the application is kinda stupid and really doesn't know if threads are required, then there probably is no harm in always linking to libpthread. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 20:10:13 2011 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C09E61065670 for ; Wed, 21 Dec 2011 20:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AFA9C8FC16 for ; Wed, 21 Dec 2011 20:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBLKAD6p064848 for ; Wed, 21 Dec 2011 20:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBLKAD46064847; Wed, 21 Dec 2011 20:10:13 GMT (envelope-from gnats) Date: Wed, 21 Dec 2011 20:10:13 GMT Message-Id: <201112212010.pBLKAD46064847@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: threads/163512: libc defaults to single threaded X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 20:10:13 -0000 The following reply was made to PR threads/163512; it has been noted by GNATS. From: Daniel Eischen To: Steven Wills Cc: freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/163512: libc defaults to single threaded Date: Wed, 21 Dec 2011 14:28:58 -0500 (EST) >> Description: > 1) libc defaults to being single-threaded > 2) thus apps not linked against libthr don't initialize the structures that threading depends on > 3) this causes bugs when said app loads a library that loads libthr > 4) said library will take the threaded code path and reference uninitialized data structures > > An example of this can be seen by removing ports/devel/p5-Glib2/files/patch-threadstest then after building, run "make test" from work/Glib-1.241. Perl will hang in state umtxn. > > I believe this may also be the source of an intermittent hang in automoc4 (also stuck in state umtxn) seen while building x11/kde4. This was discussed here: > > http://mail.kde.org/pipermail/kde-freebsd/2011-November/012211.html > https://bugs.kde.org/show_bug.cgi?id=276461 This has always been the case. If an application is going to be linked to a library that requires threads, then that application has to link to libpthread. Applications should be built knowing whether libpthread will be required or not. Either that, or the library should be built to detect whether threading is present and only use thrading features when threading is present (see how libgcc does this as example). The former or latter depends on the what the library is trying to provide. If it needs to spawn threads to accomplish its job, then the former (application needs to link with libpthread). If the library just needs synchronization primitives to protect against a threaded application, then you can use the latter. If the application is kinda stupid and really doesn't know if threads are required, then there probably is no harm in always linking to libpthread. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 16:57:41 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC681106564A; Thu, 22 Dec 2011 16:57:41 +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 23EF08FC12; Thu, 22 Dec 2011 16:57:40 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 1C8489EE476; Thu, 22 Dec 2011 16:57:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324573060; bh=rzZdSZC63JQ9PudQzLERKiudK2wP08tJeEQfgXBIB8Y=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=h7KPxFvBAvGI0wH3PBKUaAew/h0DnBfgak6PZrhxq3GfkKmsjOuG8dSYqssF1glfA 6RzBiahLNUb2PZnqL4u5PwopWMWgZ7C/BiJ/t4kNLZkThCBcMCmimXpFOT9sXCVYZd Ccm5E8OYES6sMzviImBRMyBML3ug7/5CtIgFlZzU= 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 004B59EE476; Thu, 22 Dec 2011 16:57:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324573059; bh=rzZdSZC63JQ9PudQzLERKiudK2wP08tJeEQfgXBIB8Y=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=yYClqhU/nx5gv6FmNewGcYeIHAJ6yI8tyME4XyOLJRUS62LQClAbwpkWw3ixW2mqa VcKZ1aKHQVfDCq3Ly4orUaozdrpstlfVc+aHjW1tgHs2AAIwgCCrxC2Ppi2lND0tuP FDo4B5EQXWu8Bo9UjLx8ym26a4qkTO2TLo8mfsvI= From: "Niall Douglas" To: threads@freebsd.org, arch@freebsd.org Date: Thu, 22 Dec 2011 16:57:38 -0000 MIME-Version: 1.0 Message-ID: <4EF36182.13367.C1336C10@s_sourceforge.nedprod.com> Priority: normal In-reply-to: References: , <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com>, X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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: Thu, 22 Dec 2011 16:57:41 -0000 On 21 Dec 2011 at 10:33, Warner Losh wrote: > On Dec 20, 2011, at 5:50 AM, Niall Douglas wrote: > > 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. > > Incredible claims require incredible proof. The APIs speak for > themselves: they are half-assed (and the wrong half in some cases). To > assert that they are somehow clever and we're stupid requires that one > walk through the cleverness. The participants in this thread likely > have a combined century of implementation experience with threads. That's not what I said. You're putting words in mouth. Another in this list did the same, I corrected him and here you're doing it again. Quite frankly I've had enough of the rudeness from this list. I saw questions here, I tried to answer them to the best of my ability and all I'm getting is ass whipping from people who don't even bother to read previous posts on the same topic, and quite a few who show an amazing level of emotional and technical ignorance. You can all take a running jump as far as I'm concerned. I'm not being paid to do this. I *was* trying to help. > Perhaps you can point us to the archives where all this discussion is > available? All ISO work is publicly documented from the usual channels, including rationales for all changes to draft standards documents. There's this website called "Google" which will amazingly tell you the answer. I even posted a link to the WG14 site in a previous post. Good luck with your C11 implementation freebsd-threads! I've had enough of this and I'm signing out. Oh, and merry christmas! Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 16:57:42 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE7D91065670; Thu, 22 Dec 2011 16:57:41 +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 A44078FC1B; Thu, 22 Dec 2011 16:57:41 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id CF5D59EE74C; Thu, 22 Dec 2011 16:57:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324573060; bh=cGmdbyUvQ7gpsdJ/RJhi41u4Qt98ItuGuW5XFZg3iJw=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=uKN510rTEAzskUQ6lY+eCqeByyZiePJ5OVwqZ0dNU3D1CAckkkNLoXA4qrONs+wWI qWPlZnIBBNqwHkSUK/BZCwQUU5RObXudyeG1HF7XzUEx8bJ0pG914Rq+l/CwJjnf50 BXLdGWFwsDC0nP6HSYejDkQswEKVN7aotT0gwDls= 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 A64A79EE488; Thu, 22 Dec 2011 16:57:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324573060; bh=cGmdbyUvQ7gpsdJ/RJhi41u4Qt98ItuGuW5XFZg3iJw=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=uKN510rTEAzskUQ6lY+eCqeByyZiePJ5OVwqZ0dNU3D1CAckkkNLoXA4qrONs+wWI qWPlZnIBBNqwHkSUK/BZCwQUU5RObXudyeG1HF7XzUEx8bJ0pG914Rq+l/CwJjnf50 BXLdGWFwsDC0nP6HSYejDkQswEKVN7aotT0gwDls= From: "Niall Douglas" To: threads@freebsd.org, arch@freebsd.org Date: Thu, 22 Dec 2011 16:57:38 -0000 MIME-Version: 1.0 Message-ID: <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> References: <78246.1324394062@critter.freebsd.dk>, <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: 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: Thu, 22 Dec 2011 16:57:42 -0000 On 21 Dec 2011 at 10:22, Warner Losh wrote: > When time changes in the system, as it is wont to do occasionally, then > absolute time arguments will screw you. There's no way to get them > right that isn't a massively horrible kludge. Let's say you want to > sleep for no more than 1s. You get the time, add 1s to it, get > preempted, ntpd or somebody else notices the clocks are 1 year fast and > adjusts, you get a quatum again and make the call with a timeout now > 1-year in the future. > > What could possibly outweigh that negative? As I said earlier, I don't remember what the reason was. And no, that doesn't mean it wasn't important - there is a vast volume of stuff being thrown at you during standards, if you can remember something from even a month ago you're doing well. That's why all decisions are documented in depth so it can get looked up later. Instead of shouting at me - who is trying to help you - go look it up if it matters so much to you. However, if I had to take a guess, I'd say that functional reliability can be higher when you can offer guarantees. Absolute times have higher potential of guarantees than relative, whereas the opposite is not true, because you can draw lines in the sand with absolute times and that's much harder with relative. You can also implement relative using an API taking absolute easily, whereas again the opposite is harder. I can see arguments for very long lived systems where uptime is typically in years that absolute would be a lot more reliable due to relative period drift e.g. if I want to be woken on the hour every hour, you don't want to be using a relative wait. Of course, you can then pull the system time and calculate the delta, but I digress. The point is that more information supplied to the kernel is usually better. Absolute times supply more information than relative. So there you go - and please note this paragraph is my best guess, and may have nothing to do with committee opinion. Instead of people repeatedly whinging about the system clock moving - and yes, people on standards committees are aware that system clocks can move, as they are that different cores can have different system clocks - I would be asking how does your scheduler cope with the clock moving, and how should clock syncs interact with userland? Be engineers instead of children. Ask how to solve the problem instead of complaining about split milk. Be glad you're implementing this on a POSIX system and not a non-POSIX system. Be glad there aren't a million lines of new code being needed to achieve compliance. The standard is now written in stone and is a full ISO/IEC document. Your time for helping shape it is over - we're in errata and bug fixing stage now. You should have been whinging a year or two years ago - it's not like the standard is a surprise to anyone paying attention. Its release date was widely publicised and draft spec documents are freely available over the past 18 months. I might add the C11 spec passed its last meeting with no objection from any committee member. The ISO participants consider it finished. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 16:59:18 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 CC7931065672; Thu, 22 Dec 2011 16:59:18 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8D95D8FC0A; Thu, 22 Dec 2011 16:59:18 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 759F96D85; Thu, 22 Dec 2011 16:59:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 11D3681A6; Thu, 22 Dec 2011 17:59:13 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: John Baldwin References: <73233.1324389741@critter.freebsd.dk> <86hb0ut1hq.fsf@ds4.des.no> <201112211028.26780.jhb@freebsd.org> Date: Thu, 22 Dec 2011 17:59:13 +0100 In-Reply-To: <201112211028.26780.jhb@freebsd.org> (John Baldwin's message of "Wed, 21 Dec 2011 10:28:26 -0500") Message-ID: <86zkeksftq.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , freebsd-threads@freebsd.org, freebsd-arch@freebsd.org 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: Thu, 22 Dec 2011 16:59:18 -0000 John Baldwin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Poul-Henning Kamp writes: > > > mtx_unlock(l) > > > { > > > assert(l->id =3D=3D thread_id); > > > l->id =3D NULL; > > > atomic_magic_unlock(l->lock_field) > > > } > > susceptible to race conditions > How so? I should have specified "if called from a thread that does not own the mutex" > > > mtx_assert_held(l) > > > { > > > assert(l->lock-field !=3D 0); > > > assert(l->id =3D=3D thread_id); > > > } > > susceptible to race conditions > How so? I was going to point out that the state of the mutex can change between the two asserts, but as you say, at least one of them is guaranteed to fail... *if* you assume that these fields can be read atomically, which was one of my objections. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 17:04:18 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E58EB106566C; Thu, 22 Dec 2011 17:04:18 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A59AA8FC0A; Thu, 22 Dec 2011 17:04:18 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 02A036D8E; Thu, 22 Dec 2011 17:04:15 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7C42181A9; Thu, 22 Dec 2011 18:04:14 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Hans Petter Selasky References: <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> <201112211854.40798.hselasky@c2i.net> Date: Thu, 22 Dec 2011 18:04:14 +0100 In-Reply-To: <201112211854.40798.hselasky@c2i.net> (Hans Petter Selasky's message of "Wed, 21 Dec 2011 18:54:40 +0100") Message-ID: <86vcp8sfld.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, threads@freebsd.org, freebsd-arch@freebsd.org 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: Thu, 22 Dec 2011 17:04:19 -0000 Hans Petter Selasky writes: > Absolute timeouts is no good idea! We should stick with kernel-ticks when= =20 > possible :-) There is no such thing as a kernel in the C standard. All it knows about is the implementation and the program. The best solution would probably have been a timescale that counts the time elapsed since the start of the program. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 17:06:58 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 22C8C106564A for ; Thu, 22 Dec 2011 17:06:58 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id ACAA88FC18 for ; Thu, 22 Dec 2011 17:06:57 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id pBMGuWvA064762; Thu, 22 Dec 2011 16:56:32 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id pBMGuW2n009251; Thu, 22 Dec 2011 16:56:32 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id pBMGuWHT009247; Thu, 22 Dec 2011 16:56:32 GMT Date: Thu, 22 Dec 2011 16:56:32 GMT Message-Id: <201112221656.pBMGuWHT009247@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-threads@freebsd.org In-reply-to: <4EF0DF50.9243.B766CF98@s_sourceforge.nedprod.com> References: , <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com>, <201112201009.25534.jhb@freebsd.org> <4EF0DF50.9243.B766CF98@s_sourceforge.nedprod.com> 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: Thu, 22 Dec 2011 17:06:58 -0000 >>>>> On Tue, 20 Dec 2011 19:17:36 -0000, Niall Douglas said: > > My statements come from my (prolonged) efforts to develop a safe > permit threading object for C11 as people have the tendency to roll > their own buggy implementations which just don't work right. This was > based on the Java permit primitive, but because C has function > pointers it is more flexible. You can see the last public version of > this at https://github.com/ned14/C1Xstuff/tree/ISO_TS_pre/N1572. BTW, > it needs splitting into two implementations, one for single releaser > and the other for multi releaser. > > During the very drawn out process of consulting with everyone who has > a stake in this, I probably talked to almost everyone who contributed > to the threading libraries of C (and indeed C++). The fact they > repeatedly beat my design and implementation into pieces was > immensely frustrating but in hindsight they were right. As much as > it's design by committee, there is one hell of a lot of talent in > that pool. Feel free to take this off the freebsd-threads mailing list if you think it is too off topic, but I can't find a reference to any Java primitive called a permit. NB: in general, the safest way to use pthread_cond_signal (and presumably cnd_signal) is while holding the mutex that you passed to pthread_cond_wait. If you don't do that, then you run the risk of losing the signal and having to do crazy loops like in your permit code. __Martin From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 17:08:53 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D598A106566C; Thu, 22 Dec 2011 17:08:53 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 911BA8FC12; Thu, 22 Dec 2011 17:08:53 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 33FCA5DAA; Thu, 22 Dec 2011 17:08:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBMH8p9l082796; Thu, 22 Dec 2011 17:08:51 GMT (envelope-from phk@phk.freebsd.dk) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 22 Dec 2011 18:04:14 +0100." <86vcp8sfld.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 22 Dec 2011 17:08:51 +0000 Message-ID: <82795.1324573731@critter.freebsd.dk> Cc: arch@freebsd.org, freebsd-arch@freebsd.org, threads@freebsd.org, Hans Petter Selasky 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: Thu, 22 Dec 2011 17:08:54 -0000 In message <86vcp8sfld.fsf@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >There is no such thing as a kernel in the C standard. All it knows >about is the implementation and the program. The best solution would >probably have been a timescale that counts the time elapsed since the >start of the program. That is requiring far more than necessary: All that is needed is a monotonic timescale, such as the, precisely named, CLOCK_MONOTONIC timescale POSIX introduced to solve the exact same kind of issues. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 17:52:20 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E2CA106566B; Thu, 22 Dec 2011 17:52:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 48E2C8FC25; Thu, 22 Dec 2011 17:52:20 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBMHp7pv090403 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 10:51:10 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com> Date: Thu, 22 Dec 2011 10:51:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60BA4BA7-70B9-4B4E-9139-8F6DAC303867@bsdimp.com> References: <78246.1324394062@critter.freebsd.dk>, <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com> To: "Niall Douglas" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 22 Dec 2011 10:51:10 -0700 (MST) Cc: threads@freebsd.org, arch@freebsd.org 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: Thu, 22 Dec 2011 17:52:20 -0000 On Dec 22, 2011, at 9:57 AM, Niall Douglas wrote: > Instead of people repeatedly whinging about the system clock moving -=20= > and yes, people on standards committees are aware that system clocks=20= > can move, as they are that different cores can have different system=20= > clocks - I would be asking how does your scheduler cope with the=20 > clock moving, and how should clock syncs interact with userland? Be=20 > engineers instead of children. Ask how to solve the problem instead=20 > of complaining about split milk. Be glad you're implementing this on=20= > a POSIX system and not a non-POSIX system. Be glad there aren't a=20 > million lines of new code being needed to achieve compliance. Elapsed time since boot is typically used in cases where you need a = stable, monotonically increasing time base. Changing the system time = then becomes just a change to the boot time, but not the time elapsed = since boot. A pure monotonic time base is safe to specify absolute time = in. One that isn't monotonic, such as UTC or POSIX time_t, is unsafe. = Using it is akin to specifying a mutex system that has known races that = cannot be fixed in it. I'm sorry if my harsh remarks hurt your feelings, but the new APIs do = not learn from the well known mistakes of the past decade, so they = disappoint me. Warner From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 18:28:43 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 CC919106564A; Thu, 22 Dec 2011 18:28:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0B158FC0A; Thu, 22 Dec 2011 18:28:43 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5616C46B06; Thu, 22 Dec 2011 13:28:43 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C30FDB962; Thu, 22 Dec 2011 13:28:42 -0500 (EST) From: John Baldwin To: "Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?=" Date: Thu, 22 Dec 2011 13:28:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <73233.1324389741@critter.freebsd.dk> <201112211028.26780.jhb@freebsd.org> <86zkeksftq.fsf@ds4.des.no> In-Reply-To: <86zkeksftq.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201112221328.41221.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 22 Dec 2011 13:28:42 -0500 (EST) Cc: Poul-Henning Kamp , freebsd-threads@freebsd.org, freebsd-arch@freebsd.org 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: Thu, 22 Dec 2011 18:28:43 -0000 On Thursday, December 22, 2011 11:59:13 am Dag-Erling Sm=C3=B8rgrav wrote: > John Baldwin writes: > > Dag-Erling Sm=C3=B8rgrav writes: > > > Poul-Henning Kamp writes: > > > > mtx_unlock(l) > > > > { > > > > assert(l->id =3D=3D thread_id); > > > > l->id =3D NULL; > > > > atomic_magic_unlock(l->lock_field) > > > > } > > > susceptible to race conditions > > How so? >=20 > I should have specified "if called from a thread that does not own the > mutex" You can do the same check as mtx_assert_held() internally and fail the unlo= ck=20 request in that case (or abort or what have you). > > > > mtx_assert_held(l) > > > > { > > > > assert(l->lock-field !=3D 0); > > > > assert(l->id =3D=3D thread_id); > > > > } > > > susceptible to race conditions > > How so? >=20 > I was going to point out that the state of the mutex can change between > the two asserts, but as you say, at least one of them is guaranteed to > fail... *if* you assume that these fields can be read atomically, which > was one of my objections. I do think these have to be atomic. I think lock-field must be able to be= =20 atomically read by definition. I think it is not an unreasonable requireme= nt=20 to have the implementation implement a thread_id that fits in an atomic typ= e=20 if it is not able to encode the thread_id into the lock cookie itself. I do think if l->id was not atomic it might be feasible to see a value while the thread is not locked that is equivalent to the current thread's ID based on observing different parts of l->id from different writes. There might b= e=20 ways the implementation could guard against that however. In practice thou= gh=20 I think pointers are atomic with regards to loads and stores on nearly all= =20 machines. =2D-=20 John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 18:32:35 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476C5106566B; Thu, 22 Dec 2011 18:32:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC078FC08; Thu, 22 Dec 2011 18:32:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C112646B06; Thu, 22 Dec 2011 13:32:34 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56ABEB91E; Thu, 22 Dec 2011 13:32:34 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Date: Thu, 22 Dec 2011 13:31:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> <201112211854.40798.hselasky@c2i.net> <86vcp8sfld.fsf@ds4.des.no> In-Reply-To: <86vcp8sfld.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201112221331.11031.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 22 Dec 2011 13:32:34 -0500 (EST) Cc: arch@freebsd.org, Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , threads@freebsd.org, Hans Petter Selasky 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: Thu, 22 Dec 2011 18:32:35 -0000 On Thursday, December 22, 2011 12:04:14 pm Dag-Erling Sm=C3=B8rgrav wrote: > Hans Petter Selasky writes: > > Absolute timeouts is no good idea! We should stick with kernel-ticks wh= en=20 > > possible :-) >=20 > There is no such thing as a kernel in the C standard. All it knows > about is the implementation and the program. The best solution would > probably have been a timescale that counts the time elapsed since the > start of the program. You could do relative timeouts specified in some absolute timescale like us= or=20 ns or ms. You could even use a 'struct timespec' or some such to do that=20 similar to how the it_interval member of struct itimer is used with=20 setitimer(2). That is what programmers actually want to use, and invariabl= y=20 end up implementing in a wrapper API around APIs that use absolute timeouts. =2D-=20 John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 18:32:35 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 476C5106566B; Thu, 22 Dec 2011 18:32:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC078FC08; Thu, 22 Dec 2011 18:32:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C112646B06; Thu, 22 Dec 2011 13:32:34 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56ABEB91E; Thu, 22 Dec 2011 13:32:34 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Date: Thu, 22 Dec 2011 13:31:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> <201112211854.40798.hselasky@c2i.net> <86vcp8sfld.fsf@ds4.des.no> In-Reply-To: <86vcp8sfld.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201112221331.11031.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 22 Dec 2011 13:32:34 -0500 (EST) Cc: arch@freebsd.org, Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , threads@freebsd.org, Hans Petter Selasky 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: Thu, 22 Dec 2011 18:32:35 -0000 On Thursday, December 22, 2011 12:04:14 pm Dag-Erling Sm=C3=B8rgrav wrote: > Hans Petter Selasky writes: > > Absolute timeouts is no good idea! We should stick with kernel-ticks wh= en=20 > > possible :-) >=20 > There is no such thing as a kernel in the C standard. All it knows > about is the implementation and the program. The best solution would > probably have been a timescale that counts the time elapsed since the > start of the program. You could do relative timeouts specified in some absolute timescale like us= or=20 ns or ms. You could even use a 'struct timespec' or some such to do that=20 similar to how the it_interval member of struct itimer is used with=20 setitimer(2). That is what programmers actually want to use, and invariabl= y=20 end up implementing in a wrapper API around APIs that use absolute timeouts. =2D-=20 John Baldwin