- Boost - lists.boost.org

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 07 May '13

07 May '13

> 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.

5 13

[heap] van Emde Boas tree
by Jeremy Murphy 07 May '13

07 May '13

Should I contact Tim Blechmann directly about the idea of adding a van Emde Boas tree to Boost.Heap, or is proposing it here the appropriate way to go about it? Thanks, cheers. Jeremy

2 1

[any] Divergence between Boost.Any and standard library proposal
by Beman Dawes 07 May '13

07 May '13

A fresh draft of the proposal is up at http://beman.github.com/dot16/any-proposal.html In testing new any_cast examples, Boost.Any is handling one case differently from the proposal: any x; ... x = "Meow"; // x holds const char* This works fine with the Adobe implementation, but with the Boost implementation g++ 4.7.0 -std=c++11 reports: In file included from any_cast_test.cpp:5:0: c:\boost\trunk/boost/any.hpp: In instantiation of 'boost::any::holder<ValueType>::holder(c onst ValueType&) [with ValueType = char [5]]': c:\boost\trunk/boost/any.hpp:52:49: required from 'boost::any::any(const ValueType&) [wi th ValueType = char [5]]' c:\boost\trunk/boost/any.hpp:124:13: required from 'boost::any& boost::any::operator=(Va lueType&&) [with ValueType = const char (&)[5]; boost::any = boost::any]' any_cast_test.cpp:79:7: required from here c:\boost\trunk/boost/any.hpp:169:27: error: array used as initializer VC++ 2012 gets the same error, albeit with a much longer set of messages. AFAICS, the Adobe (and the proposed standard) behavior is preferred. The type does need to decay. Comments? --Beman

6 10

[chrono/date] date conversion and arithmetic with unvalidated dates
by Vicente J. Botet Escriba 07 May '13

07 May '13

Hi, Note that N3344 suggest only day arithmetic for a day representation (which is always valid) and suggest only only a date representation. Could we apply arithmetic operations on a unvalidated date (without striving on UB)? e.g. day arithmetic on a ymd_date ymd_date d1(year(2013), may, day(66)); ymd_date d2 = d1 + day(1); If defined, which must be the value of d2? Could we convert a date representation to another one if the source date is unvalidated (without striving on UB)? e.g. ymd_date -> days_date ymd_date d1(year(2013), may, day(66)); days_date d2 = d1; If defined, which must be the value of d2? Best, Vicente

4 5

[chrono/date] validated versus valid dates
by Vicente J. Botet Escriba 07 May '13

07 May '13

Hi, Allowing to build dates that are not validated doesn't mean that they are not valid. A validated date is always valid. E.g date d(year(2013), may, day(5)); d is not a validated date but is valid. Having a is_validated() function in addition to is_valid() could have its uses assert( ! d.is_validated() && d.is_valid() ); is_validated() function forces to use a bit to store this information on the date representation, but it improves the performances of the is_valid() function. Moving from a possible unvalidated to a validated one would need date d1; ... date d2(d1.year(), d1.month(), d1.day(), check); Instead of this a validate factory makes this clearer date d1; ... date d2 = validate(d1); date validate(date const& dt) { if (dt.is_validated()) return *this; else if (dt.is_valid()) { date res(dt); res.set_validated_(); // this is private return res; } throw bad_date(); } Best, Vicente

2 3

Am I missing something or is Boost: String dictionary?
by david.hagood＠gmail.com 06 May '13

06 May '13

One of the libraries I work with (libXML2) has a very useful concept called a string dictionary, and I am surprised this doesn't appear to be in either STL or Boost. Am I missing something, or is Boost missing something? The basic idea is: Given you have a string and an instance of a dictionary, you can: 1) check if the string is already in the dictionary. 2) Add the string to the dictionary and return the dictionary entry (if the string is already present, return existing entry). The dictionary entries contain a copy of the string. Entries may be compared for equality/inequality in O(1) time. The lifespan of the strings in the entry is managed by the entry. This really simplifies writing parsers and the like, and is such a useful concept that I'm really surprised not to see it in STL or Boost.

6 6

[GitHelp]github.com/boostorg/sandbox comment confusing
by Larry Evans 06 May '13

06 May '13

At: https://github.com/boostorg/sandbox there's a comment by Beman from 10 yrs ago saying: Removed as obsolete - use Boost.Random instead which makes no sense to me. Also, are any of the sandbox files from svn going to be moved to this github sandbox? TIA. -regards, Larry

3 4

Fwd: GSOC:2013 Multiprecision Proposal Review
by Siddharth Jain 06 May '13

06 May '13

Please have a look at my proposal. The link to my proposal is http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/siddhart… and I have worked a lot on this proposal. Please suggest any changes which could be incorporated to improve this project. Regards Siddharth Jain

1 0

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 06 May '13

06 May '13

> Le 02/05/13 18:01, Niall Douglas a ?crit : > >> That's orthogonal. Boost.Asio provides the funding blocks. A nicer > >> interface that doesn't require an explicit continuation passing style > >> transformation can be built with Boost.Context or a similar library. > >> But it probably needs a future implementation that integrates with > >> ASIO, which is one of the point of Niall Douglas. > > Spot on. Especially as parts of ASIO are due to enter with TR2. I worry that > > a thread pool designed without ASIO in mind would become an orphan isolate. > What a ThreadPool must provide to satisfy the ASIO requirements? That's a very good question. And for me to answer in specifics I'd need to think deeply about the issue, and study examples, neither of which time currently allows given C++Now is just around the corner. All I can say right now - and I agree this isn't very helpful - is make it compatible with opaque third party event loop dispatchers such as Qt's QCoreApplication and QRunnable. Because Qt's implementation details iare opaque to external code, if you can meet compatibility with that you'll probably be compatible with anything Boost.ASIO can come up with, especially as most of Boost.ASIO is header defined. I appreciate that isn't very helpful. Thread pool design is hard :( Niall

4 5

[config/multiprecision/units/general] Do we have a policy for user-defined-literals?
by John Maddock 06 May '13

06 May '13

Folks, I've been experimenting with the new C++11 feature "user-defined-literals", and they're pretty impressive ;-) So far I've been able to write code such as: auto i = 0x1234567890abcdef1234567890abcdef_cppi; and generate value i as a signed 128-bit integer. It's particulary remarkable because: * It actually works ;-) * The value is generated as a constexpr - all evaluation and initialization of the multiprecision integer is done at compile time. * The actual meta-code is remarkably short and concise once you've figured out how on earth to get started! Note however my code is limited to hexadecimal constants, because it can't do compile time radix conversion - that would require a huge meta-program for each constant :-( This is obviously useful to the multiprecision library, and I'm sure for Units as well, but that leaves a couple of questions: 1) We have no config macro for this new feature (I've only tested with GCC, and suspect Clang is the only other compiler with support at present). What should it be called? Would everyone be happy with BOOST_NO_CXX11_USER_DEFINED_LITERALS ? 2) How should libraries handle these user defined suffixes? The essencial problem is that they have to be in current scope at point of use, you can never explicitly qualify them. So I suggest we use: namespace boost{ namespace mylib{ namespace literals{ mytype operator "" _mysuffix(args...); }}} Then users can import the whole namespace easily into current scope right at point of use: int main() { using namespace boost::mylib::literals; boost::mylib::mytype t = 1234_mysuffix; } 3) How should the suffixes be named? There is an obvious possibility for clashes here - for example the units lib would probably want to use _s for seconds, but no doubt other users might use it for strings and such like. We could insist that all such names added to a boost lib are suitably mangled, so "_bu_s" for boost.units.seconds, but I'm not convinced by that. Seems to make the feature much less useful? Many thanks in advance for your thoughts, John.

6 12