Re: [boost] [thread] thread_specific_ptr performance (was: Re: Boostlibrary submission (poll for interest))

Subject: Re: [boost] [thread] thread_specific_ptr performance (was: Re: Boostlibrary submission (poll for interest))
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-01-08 14:36:46

----- Original Message ----- 
From: "Stefan Strasser" <strasser_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, January 08, 2010 7:37 PM
Subject: [boost] [thread] thread_specific_ptr performance (was: Re: Boostlibrary submission (poll for interest))

> 
> Am Friday 08 January 2010 16:39:27 schrieb Rutger ter Borg:
>> 1) Transactional semantics: wouldn't it be easier to steal semantics from
>> locks in threads? E.g., for the synchronous interface case, wouldn't
>>
>> map_type m_map;
>> try {
>>   scoped_transaction trans( m_map );
>>   ..
>>   .. do stuff with the map
>>   ..
>>   trans.commit();
>> }
>> catch( transaction_error ) {
>> }
>>
>> be a easier than passing the transaction everywhere?
> 
> implementing this requires a call to thread_specific_ptr::get() on each 
> operation to obtain the active transaction.
> 
> unfortunately thread_specific_ptr is implemented using pthread calls and a 
> std::map lookup, so this consumes > 6% CPU in one of my test cases.
> and this is a real world test case with other expensive stuff, in cases that 
> e.g. only read cached objects it's probably even worse.
> 
> is there any chance for a thread_specific_ptr implementation based on GCC 
> __thread and MSVC __declspec(thread)?
> 
> __thread results in a simple read access using a thread-specific memory 
> segment.

Hi,
As Anthony has already state on other threads this seems to be not posible (the semantic is different).
What about defining a macro BOOST_LOCAL_THREAD that do the needed portable issues?
Have you make some measures with __thread and/or MSVC __declspec(thread)?

BTW, Anthony has made some improvements to which thread_specific_ptr in 1.41. Which version are you using?

Best,
Vicente