Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of francis.andre@easynet.fr
 designates 212.180.1.180 as permitted sender)
Message-ID: <47F0DCE1.7050403@easynet.fr>
Date: Mon, 31 Mar 2008 14:45:21 +0200
From: Francis ANDRE <francis.andre@easynet.fr>
Organization: PAC MPE
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [drlvm] thread local storage in open/hythread.h
References: <3b3f27c60803290943y1d5a72dbg84cc30da612e93eb@mail.gmail.com>
	 <200803310141.07513.gshimansky@apache.org>
	 <3b3f27c60803301828g22de0cd0h814f9b530961614@mail.gmail.com>
 <ca4b22060803310404n5ea3c434h282a23434994dfbe@mail.gmail.com>
In-Reply-To: <ca4b22060803310404n5ea3c434h282a23434994dfbe@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

 >> Do you have any suggestions or preferences about a particular TLS
 >> approach? I'm all for fast, but I tend to lean towards a consistent
 >> (single) clean approach, even it it's not the fastest approach.

What would you think about using the zthread package as general rule and using 
optimal hand coded part for optimization??
http://zthread.sourceforge.net/

Francis

Pavel Rebriy a écrit :
> Nathan,
> 
> TLS access is a performance critical function, that why unified (single,
> clean) approach could have 20-30% of performance degradation on some
> benchmarks.
> 
> On 31/03/2008, Nathan Beyer <nbeyer@gmail.com> wrote:
>> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
>> <gshimansky@apache.org> wrote:
>>> On 29 марта 2008 Nathan Beyer wrote:
>>>  > In open/hythread.h there is the following bit of code.
>>>  >
>>>  > #ifdef PLATFORM_POSIX
>>>  > extern __thread hythread_t tm_self_tls;
>>>  > #else
>>>  > extern __declspec(thread) hythread_t tm_self_tls;
>>>  > #endif //PLATFORM_POSIX
>>>  >
>>>  >
>>>  > hy_inline hythread_t VMCALL hythread_self() {
>>>  >     return tm_self_tls;
>>>  > }
>>>  >
>>>  > From what I know at the moment, the use of '__thread' isn't a POSIX
>>>  > standard, but rather a gcc extension and '__declspec(thread)' is a
>>>  > MSVC thing, so the check isn't quite correct. Neither of these works
>>>  > on MacOS X and from what I've been able to gather, it shouldn't work
>>>  > on FreeBSD, but I can't confirm that. In any case, I was looking at
>>>  > implementing this for MacOSX and FreeBSD using pthread_key_t. It
>> seems
>>>  > like that could be used for other (all?) platforms as well. Any
>>>  > thoughts on that?
>>>
>>>  AFAIK there are plenty of different implementation for getting TLS in
>> DRLVM's
>>>  implementation of hythread. There are fast ways like those you've
>> mentioned,
>>>  slow ways using APR and pthread and very fast ways using inline
>> assembly.
>>>  All of them are quite messed up right now and need some cleaning. The
>> mess is
>>>  with different defines that rule the whole stuff - it is not always
>> clear
>>>  which define set is used for a particular implementation on a given
>> platform.
>>
>>
>> I would agree that the defines are a bit of a mess or at least seem
>> like it at times.
>>
>> Do you have any suggestions or preferences about a particular TLS
>> approach? I'm all for fast, but I tend to lean towards a consistent
>> (single) clean approach, even it it's not the fastest approach.
>>
>>>  --
>>>  Gregory
>>>
> 
> 
>