Boost logo

Threads-Devel :

From: Kai Brüning (kai_at_[hidden])
Date: 2007-01-26 14:05:19


Hi,

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.

Best,
Kai

>Roland Schwarz <roland.schwarz_at_[hidden]> writes:
>
>> Kai Brüning wrote:
>>
>>> Why does thread::thread wait till the thread
>>> is started (at least in 1.33.1)?
>>
>> I am not sure I understand your question. Can you please try to be more
>> specific?
>>
>> There is no explicit mechanism to wait, basically this property is
>> inherited from the respective low level API.
>
>thread::thread(func) constructs a new thread_param object, and creates a
>thread, set to run at thread_proxy, passing in the address of the thread_param
>object. It then calls param.wait() to ensure that the thread has started.
>
>This is to ensure that the function object has been correctly copied into the
>context of the new thread before the thread constructor returns --- this is
>done by thread_proxy, which copies the function object, notifies the
>thread_param, and then calls the function.
>
>If this did not happen, then it becomes much harder to use function objects
>with threads, as you need to ensure that the object referenced by the
>newly-created thread has not already been destroyed, which essentially
>requires it to be heap allocated.
>
>Anthony
>--
>Anthony Williams
>Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
>Registered in England, Company Number 5478976.
>Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
>_______________________________________________
>threads-devel mailing list
>threads-devel_at_[hidden]
>http://lists.boost.org/mailman/listinfo.cgi/threads-devel

-- 
RagTime GmbH                          Tel: [49] (2103) 9657-0
Neustraße 69                          Fax: [49] (2103) 9657-96
D-40721 Hilden                        mailto:kai_at_[hidden]
Deutschland                           http://www.RagTime.de/

Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk