Boost logo

Boost :

From: Gavin Lambert (boost_at_[hidden])
Date: 2020-03-08 23:04:40

On 6/03/2020 22:47, Adham Sabry wrote:
> where can i find the duration of sleep that basic_thread_pool does then
> wakes up???it sleeps till some methods like submit are called.i thought
> submit just make tasks without starting the thread and async is the one
> which launch thread but i was totally wrong drived by asio paradigm
> what is the reason of wake up??is it timed internally or it needs explicit
> launching?we can do both using schedulers although i do not know how
> also why async leads to pausing test_executor_adaptor???here async return
> is assigned to variable t2 so it will not block in async destructor,but
> will work asynchronously till the scope is ended and then block in
> destructor of async???this i do not know answer to it????why async pause ???
> what do you mean by sleeping?you meant to sleep between submit calls so
> they are finished

There is no specific time. The threadpool threads are asleep waiting
for work to be submitted.

As soon as you actually submit work (whether directly via submit() or
indirectly via async()), the thread is eligible to wake up (in fact it
might wake up and complete the work before submit even returns) -- that
part is entirely up to your OS's thread scheduler.

If it helps: async() is essentially internally just a call to submit()
with some additional wrapping to give you a future representing the
completion of the operation. [This is not precisely accurate but it's a
good way to think about it for understanding purposes.]

My point about the async calls is that because you're calling async and
then future.get(), you're blocking the original thread waiting for
something else, which allows the threadpool work to complete in the
background, regardless of which threadpool the work was submitted to.

If you completely removed the future.get() calls (even if you still
called async), then you might end up destroying the threadpool before it
actually did the work, thus it would appear that submit() did nothing.
(And the asyncs would also end up doing nothing.) But because like I
said this is up to your OS's thread scheduler, it might sometimes make
some progress on some of the work before actually being destroyed, which
can be confusing.

If you have a sleep (or any other work running long enough) in there, so
that you don't destroy the threadpool too soon, then it will complete in
the background.

Usually you need to structure your code in a way that assures that the
things you want to complete have actually completed before you destroy
them. Waiting on futures is an easy way to do that in a toy example,
but it can get more complex in a real application. (I personally
consider futures almost entirely useless in a real application -- but
that doesn't make learning about them useless.)

I'd recommend finding a good book on the topic to read. (Though books
specifically on executors are probably rare, as it's relatively new
ground.) Threading and async in C++ can be very hard to get correct
unless you have the fundamentals down strongly.

Boost list run by bdawes at, gregod at, cpdaniel at, john at