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

Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-01 17:08:00

Le 01/05/13 20:39, Niall Douglas a écrit :
>> 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.
It is just that I don't know the term.
As I don't know the domain (the words) you are talking about we can stop 
the exchange here if you prefer, or you could continue to explaining me 
the things I don't know/understand.
>
> 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.
In order to be sure I understand what you say could you tell me how a 
decentralized asynchronous dispatcher behaves? What are the differences?
>
>>>> 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.
Are you saying that current TM technology should be much more useful for 
centralized than decentralized asynchronous dispatchers?
Does this means that the whole application would improve its 
performances using always centralized asynchronous dispatchers?
>
>>> 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).
I know this proposal. Could you explain me how it is related to 
Boost.Asio? Could you point me where in the Asio documentation could I 
find related information?
>   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.
>
Thanks Niall for all the explanations and sorry if all this is trivial 
for you.
Vicente