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

From: Kai Brüning (kai_at_[hidden])
Date: 2007-02-05 16:32:05

>"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.
>
>Anthony

My main concern is not the relative performance of heap allocation versus mutex/cond var but the delay of the thread which creates the new thread imposed by waiting until the new thread is up and running. I have little experience with thread-relate timings and didn't do any timing tests, therefore I may be completely wrong, but: currently the first thread has to wait through at least two context switches plus whatever time it takes until the new thread enters its main function until it can continue. I would expect that this is substantially longer than the time taken by the OS thread creation function. And it forces at least one additional context switch which would be saved without the wait. If the new thread has lower priority than the creating thread, it will probably be two additional context switches.
Note: this is not a problem I am having with actual code written against boost.thread. These are just thoughts that came to my mind when looking at the implementation.

Best,
Kai

-- 
Kai Brüning * Geschäftsführer
RagTime GmbH * http://www.ragtime.de
Neustraße 69 * 40721 Hilden * Deutschland
Tel: [49](0)2103 9657-0 * Fax: [49](0)2103 9657-96
Sitz der Gesellschaft: Hilden * Amtsgericht Düsseldorf HRB 45697
Geschäftsführer: Kai Brüning, Helmut Tschemernjak