Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project

Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-05-01 14:39:44

> Le 30/04/13 17:16, Niall Douglas a ?crit :
> >> Le 29/04/13 21:35, Niall Douglas a ?crit :
> >> Could you explain me what a central asynchronous dispatcher is?
> > An asynchronous procedure call implementation. Here's Microsoft's:
> > http://msdn.microsoft.com/en-
> us/library/windows/desktop/ms681951(v=vs.85).as
> > px. Here's QNX's:
> http://www.qnx.com/developers/articles/article_870_1.html.
> > Boost.ASIO is the same thing for Boost and C++ but implemented by
> > application code. It is *not* like asynchronous POSIX signals which are
a
> > nearly useless subset of APCs.
> I don't see the term "central asynchronous dispatcher" used in any of
> the links. Could you clarify what it is?

I have to admit I'm struggling to see where your block is, but Dave Abrahams
often found the same with me, so it must be me.

A central asynchronous dispatcher is the loop which sends callbacks/events
to be invoked/processed by other execution contexts. Every OS has at least
one in the kernel. Most GUI toolkits like Qt have one. Boost has at least
one in the form of Boost.ASIO.

The central means one execution context does the dispatch. The asynchronous
means that callbacks are processed by recipients asynchronous to the
dispatcher. And dispatcher, well that dispatches.

> >> If not, please could you elaborate what kind of optimizations can be
> >> obtained?
> > If you have transactional memory in particular, you gain multi-CAS and
the
> > ability to (un)lock large ranges of CAS locks atomically, and a central
> > dispatcher design can create batch lists of threading primitive
operations
> > and execute the batch at once as a transaction. Without TM, you really
need
> > the kernel to provide a batch syscall for threading primitives to see
large
> > performance gains.
> I'm really lost.

Multi-word Compare-And-Swap (MCAS) is one of the biggest gains from
Transactional Memory. Indeed WG21 has SG5 dedicated to integrating TM into
C++17. Some models of Intel's Haswell come with hardware TM assist.

I'd take a reasonable guess that MCAS will benefit centralized kernel-based
threading primitives architectures such as Windows NT more than
decentralized threading primitive architectures such as POSIX. That said, I
could see Linux using TM for batch multi-kernel-futex ops, though I'd have
to say implementing that without breakage would be daunting.

Either way, a central asynchronous dispatcher has information a
decentralized implementation does not. That opens more scope for
optimization.

> > Boost.ASIO's core is boost::asio::io_service. That is its dispatcher
> > implementation which each dispatch execution context being executed via
> > boost::asio::io_service::run() which is effectively an event loop. Third
> > parties then enqueue items to be dispatched using
> > boost::asio::io_service::post(). You don't have to run Boost.ASIO using
> > multiple threads: it can be single threaded.
>
> I could not comment until I understand what Boost.ASIO provides and it
> can interact with thread_pools :(

Boost.ASIO provides a per-thread capable event loop implementation. That
automatically makes it an example of a thread pool manager.

You may find N3562 Executors and schedulers coproposed March 2013 for
Bristol by Google and Microsoft of use to you in understanding the relation
between thread pools and Boost.ASIO
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3562.pdf). My
proposed Boost.AFIO library is an implementation of that same N3562 idea,
albeit I extend Boost.ASIO which is IMHO more C++-y whereas Google and
Microsoft have gone with proprietary implementations. Also, they include
timing and many other more general purpose features, and mine does not
(currently) as it's mainly aimed at maximising input/ouput with highly
jittery random latency storage.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.