Re: [boost] [move] new rvalue reference emulation

Subject: Re: [boost] [move] new rvalue reference emulation
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2012-01-31 03:48:41

On 30/01/12 18:44, Dave Abrahams wrote:
>
> on Mon Jan 23 2012, "Jeffrey Lee Hellrung, Jr."<jeffrey.hellrung-AT-gmail.com>  wrote:
>
>> On Mon, Jan 23, 2012 at 10:16 AM, Vicente J. Botet Escriba<
>> vicente.botet_at_[hidden]>  wrote:
>>
>> at least, I'm guessing thread is pimpl'ed
>
> Reading this surprised me so much that I had to look for myself, and
> indeed it does seem to be pimpl'ed.  My understanding was that the
> move-only threading components were designed so that they could be
> implemented as efficiently as possible, without dynamic allocation, and
> I wonder why Boost's implementation would be less efficient.

"Efficiency" is in the eye of the beholder. The thread function supplied 
to the OS has to have various bits of data from the boost::thread 
constructor, not least of which the function (object) to call and its 
parameters. It has to store these somewhere that persists (at a fixed 
address) for the life of the thread, even if the boost::thread object is 
moved, or the thread is detached.

One option is to allocate it dynamically, and pass in the pointer to the 
newly-allocated object to the thread function. The advantage here is 
that the boost::thread constructor doesn't have to wait for the thread 
to actually be scheduled by the OS, but the disadvantage is that it uses 
dynamic allocation.

The second option is to wait for the thread to start, have the thread 
function allocate some memory off its own stack and pass the address 
back to the boost::thread constructor, which can then populate the 
memory with the necessary data before signalling the thread function to 
continue. The advantage here is that there is no dynamic allocation. The 
disadvantage is that the boost::thread constructor has to wait for the 
thread to be scheduled by the OS, and then there is back-and-forth 
communication.

There may be a third option but I cannot think of one just now.

Boost.Thread uses the first option because it returns control to the 
code that started the thread sooner, and does not wait for the OS to 
schedule the thread. It's a trade-off, so reasonable people may disagree 
with the choice.

Anthony
-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976