Re: [PATCH v4] Make bindresvport() function to multithread-safe

[Peng Haitao <penght at cn dot fujitsu dot com>]

On 10/19/2012 03:58 AM, Rich Felker wrote:
>> I think that using __thread here increases concurrency in the library
>> without the cost of locking which can require a local CPU to take
>> ownership of an entire cache line. That cache line may contain more
>> than just the data we wanted to work with.
>>
>> The two scenarios are:
>>
>> (a) Mutex
>> - Decreased concurrency.
>> - Every program increase .data by sizeof(mutex) (maybe 40-50 bytes).
>> - Function is now thread safe.
> 
> Isn't there some internal lock type that's only 4 or 8 bytes rather
> than a whole pthread_mutex_t?
> 

Using __libc_lock_lock(NAME) is OK?
Just as patch v2: http://sourceware.org/ml/libc-alpha/2012-09/msg00507.html

Thanks.

-- 
Best Regards,
Peng

>> (b) __thread
>> - Increased concurrency.
>> - Every thread increases .tdata by sizeof(short) (maybe 4 bytes with alignment).
>> - Function is now thread safe.
>>
>> I don't see that the answer is that clear cut.
>>
>> Given the future of lots and lots of cores I'd rather debug (b).
>>
>> Rich, Why do you lean towards (a)?
> 
> A couple reasons...
> 
> (1) Use of this function is extremely rare, so it should be optimized
> towards not adding cost in programs that don't use it.
> 
> (2) The runtime cost of this function is bounded by syscalls, so
> optimizing userspace code for performance is mostly useless. (Not
> entirely since the locking cost could invalidate cache in other
> threads, but I still suspect this will be very rare.)
> 
> Of course for this one function, the cost (a few bytes of TLS) does
> not matter. I'm more thinking from a general policy perspective;
> adding TLS all over the place will eventually add up. It would be even
> worse if this were initialized TLS, since that adds runtime cost too.
> 
> Rich
>