Re: [Threads-devel] Why does thread::thread wait till the thread is started?

From: David Abrahams (dave_at_[hidden])
Date: 2007-02-01 16:48:25

Anthony Williams <anthony_at_[hidden]> writes:

> "Kai Brüning" <kai_at_[hidden]> writes:
>
>> I thought a little more about this topic. I am rather new to concurrent
>> programming, and the most important lesson so far was that you typically
>> overlook something, so it is quite likely that I do overlook something here,
>> too, but anyway:
>>
>> Looks to me that indeed heap-allocating the function object might be the
>> better solution. That is, thread::thread would create a copy of the function
>> object on the heap and pass the pointer as parameter to
>> thread_proxy. thread_proxy would than execute the function object and delete
>> the pointer after returning. This would remove the whole condition variable
>> and mutex overhead at the cost of a single heap allocation. I have no idea
>> of the inner workings of a pthread condition variable, but since it needs to
>> keep a list of waiting threads, it is not unlikely that at least one heap
>> allocation happens anyway.
>>
>> The function object is copied once in both cases, currently in thread_proxy
>> from thread_param to the thread stack, this would move to copy-construction
>> into the heap block in thread::thread.
>
> As you say, it's a trade-off --- heap allocation vs mutex/cond var. I can't
> think of a particular reason why your scheme wouldn't work, but I guess Bill
> didn't want to require a heap allocation for some reason.

It's almost a sure bet that something like the small string
optimization could be used to eliminate heap copies in 99% of cases.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com