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.