Re: Boost.Asio as "thread-pool": How to apply back-pressure?

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-02-09 17:59:57

On 09/02/2021 15:13, Dominique Devienne via Boost-users wrote:

>     I think choosing a better framework for your use case would make your
>     life awfully easier. Grand Central Dispatch works very well on Mac OS
>     and FreeBSD, and is built into the system. The port of GCD (libdispatch)
>     to Linux is acceptable. On Windows, you want the Win32 thread pool,
>     totally different API, but does the same thing.
> 
> 
> Thanks for your answer Niall. But sounds to me that what you are proposing
> is a large project in and of itself, versus tweaking a portable
> Boost.Asio-based
> existing program, to use less memory.

I agree that the learning curve for a new API will be quite steep
initially. But GCD's API is quite nicely designed, it's intuitive, and
it "just works".

I can't say that the Win32 thread API is as nicely designed. It *is*
very flexible and performant, but a lot of it is "non-obvious" relative
to GCD's API design.

On the other hand, if you implement a GCD based implementation, you'll
#ifdef in a Win32 thread API implementation quite easily.

> I've thought myself of a few approaches, but none seem very appealing, and
> some likely would stall / block some task (via cond-vars for example),
> starving
> ASIO of some of its threads, so less than ideal.
> 
> Surely I'm not the only one who ever tried something like this, no?

This is the beauty of GCD-like implementations. You don't need to think
about load nor scheduling, except in the highest level. You just feed
work to GCD, tell it the priority for each work item, GCD figures out
how best to execute it given your system's *current* conditions.

In other words, if half your CPUs are currently at 100%, GCD _only_
occupies the other half of your CPUs. It automatically scales up, or
down, concurrency according to your workload e.g. if your work item
stalls in a sleep, or a syscall, GCD automatically notices and increases
concurrency. If there are too many work items currently running for
system resources, GCD automatically notices and decreases concurrency.

This is very nice, and getting ASIO to do the same is a lot of extra work.

>     You may find the unfinished low level prototype platform abstraction of
> 
>     these facilities at https://github.com/ned14/llfio/pull/68
>     <https://github.com/ned14/llfio/pull/68> useful to
>     study when designing your own integration. It works well on GCD and
>     Win32 thread pools. Its native Linux backend is not usable yet. I hope
>     to send it WG21's way for study before April.
> 
> 
> I'll have a look, out of curiosity. But I need Windows/Linux portability,
> and as outlined above something a bit more approachable for a mere
> mortal like me.

If you ignore the Linux native backend i.e. assume
LLFIO_DYNAMIC_THREAD_POOL_GROUP_USING_GCD=1 or _WIN32=1, you'll note
that the implementation reduces down to not much code at all. There is
approximately a one-one relationship between GCD and Win32 thread API calls.

My suggestion is concentrate on GCD, and use my code in the PR to
"translate" the GCD APIs to their equivalents in the Win32 thread API.

You may want to try out a little toy prototype to get a feel for the GCD
API. I think you'll find you like it. apt install libdispatch-dev should
do it. Apple have good API documentation for it on their website.

Niall