Re: boost thread strange behaviour

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.