Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk