From owner-freebsd-threads@FreeBSD.ORG Mon Jun 16 19:02:32 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B604837B401 for ; Mon, 16 Jun 2003 19:02:32 -0700 (PDT) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id F372543F3F for ; Mon, 16 Jun 2003 19:02:31 -0700 (PDT) (envelope-from kabaev@mail.ru) Received: from [151.203.235.42] (port=55934 helo=kan.dnsalias.net) by mx3.mail.ru with esmtp id 19S5nq-0003tX-00; Tue, 17 Jun 2003 06:02:30 +0400 Received: from kan.dnsalias.net (ak03@localhost [127.0.0.1]) by kan.dnsalias.net (8.12.9/8.12.9) with ESMTP id h5H22STI090577; Mon, 16 Jun 2003 22:02:29 -0400 (EDT) (envelope-from kan@kan.dnsalias.net) Received: (from kan@localhost) by kan.dnsalias.net (8.12.9/8.12.9/Submit) id h5H22SXV090576; Mon, 16 Jun 2003 22:02:28 -0400 (EDT) Date: Mon, 16 Jun 2003 22:02:28 -0400 From: Alexander Kabaev To: Gareth Hughes Message-Id: <20030616220228.49672fc7.kabaev@mail.ru> In-Reply-To: <2D32959E172B8F4D9B02F68266BE421401A6D7E8@mail-sc-3.nvidia.com> References: <2D32959E172B8F4D9B02F68266BE421401A6D7E8@mail-sc-3.nvidia.com> X-Mailer: Sylpheed version 0.9.0claws2 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: Not detected cc: threads@freebsd.org cc: zander@mail.minion.de cc: 'Julian Elischer' cc: Andy Ritger cc: Daniel Eischen Subject: Re: NVIDIA and TLS X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2003 02:02:33 -0000 On Mon, 16 Jun 2003 18:43:50 -0700 Gareth Hughes wrote: > No, this is simply not true. > > If your thread library implementation is that much better than > anything else out there, simply support the dynamic access models > (General Dynamic and Local Dynamic) only. You do not understand. Whether or not it is better only time will tell. ELF TLS standard is defined in a way, that only a _specific_ threads implementation can reap full benefits, most other are penalized by the segment access reloads on every thread context switch. > > One of the benefits of the Linux implementation is that it allows > the static TLS access methods (Initial Exec and Local Exec) to be > used. If your implementation fundamentally can't support these > access models, then just don't support them. So the choice is either to pay penalty implementing TLS through callable entry, or by making context switches more expensive than they have to be. I am obviously not thrilled with the standard, but I guess I'll have live with it since I have nothing better to offer on my own anyway.