- Boost-users - lists.boost.org

Shared memory: private node allocator for a boost::unordered_map
by trafdev 12 May '16

12 May '16

Hello. I'm trying to use a private node allocator for an unordered_map placed in the shared memory: #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/containers/map.hpp> #include <boost/unordered_map.hpp> #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/allocators/private_node_allocator.hpp> #include <functional> #include <utility> int main () { using namespace boost::interprocess; struct shm_remove { shm_remove() { shared_memory_object::remove("MySharedMemory"); } ~shm_remove(){ shared_memory_object::remove("MySharedMemory"); } } remover; managed_shared_memory segment (create_only ,"MySharedMemory" //segment name ,65536); //segment size in bytes typedef int KeyType; typedef float MappedType; typedef std::pair<const int, float> ValueType; typedef private_node_allocator<ValueType, managed_shared_memory::segment_manager> ShmemAllocator; typedef boost::unordered_map<KeyType, MappedType, boost::hash<KeyType>, std::equal_to<KeyType>, ShmemAllocator> MyMap; ShmemAllocator alloc_inst (segment.get_segment_manager()); MyMap *mymap = segment.construct<MyMap>("MyMap") //object name (3, boost::hash<KeyType>(), std::equal_to<KeyType>(), alloc_inst); for(int i = 0; i < 100; ++i){ mymap->insert(std::pair<const int, float>(i, (float)i)); } return 0; } It gives a compilation error: /usr/local/include/boost/unordered/detail/unique.hpp:30:43: error: no type named 'pointer' in 'boost::interprocess::private_node_allocator<boost::unordered::detail::unique_node<boost::interprocess::private_node_allocator<std::__1::pair<const int, float>, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0>, 0>, iset_index>, 64>, std::__1::pair<const int, float> >, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0>, 0>, iset_index>, 64>' A, unique_node<A, T> >::type::pointer node_pointer; What am I doing wrong?

2 1

[boost.lockfree][spsc_queue] runtime sizing and producer's thread
by Sampath Tilakumara 12 May '16

12 May '16

Hi, Two questions on lockfree spsc_queue: 1. Can spsc_queue be dynamically (runtime) sized, and if so how do you correctly do it? * Creating a mpmc queue with size 0 (i.e. queue<T>(0)) creates a dynamically sizes mpmc queue, but doing the same for spsc queue doesn't. * creating a spsc queue with size 10 (i.e. queue<T>(10)) seems to create a fixed sized ring buffer since at high transfer rates, push fails, however the constructor code that takes the size asserts that it's runtime sized. explicit spsc_queue(size_type element_count): base_type(element_count) { BOOST_ASSERT(runtime_sized); } * documentation mentions lockfree::fixed_sized<> in policies, and can also be found in (mpmc) queue.hpp, but it doesn't seem to be in spsc_queue.hpp * all examples I could find on the internet (and documentation) was for fixed size or for mpmc dynamic, but not for spsc dynamic. 2. In a normal (spsc using) program the producer will be a single OS thread; however is it still safe to use on something like an actor framework or fiber framework? (i.e. you only have a single producer object, but it can actually be executed in different threads -- though strictly on one thread at any given time). for example in spsc_queue.hpp there's some code such as: bool push(T const & t, T * buffer, size_t max_size) { const size_t write_index = write_index_.load(memory_order_relaxed); // only written from push thread Refs on actors/fibers: https://en.wikipedia.org/wiki/Fiber_%28computer_science%29 https://en.wikipedia.org/wiki/Actor_model Thank you. Sampath Tilakumara

2 1

FindBoost.cmake does not check for include headers
by j.wuttke 11 May '16

11 May '16

As per cmake 3.5.1, FindBoost.cmake does not check for include headers. Therefore it will give false positives - if a Boost project that only consists of a header file is not installed - if only a libboost* is installed, but not the headers from the corresponding *-dev package. I raised this issue long ago on the cmake bug tracker, and recently again on the cmake mailing list, but got no response. Would perhaps somebody from the Boost community volunteer to look into this issue? Or has already looked into it and could tell us what the problem is?

3 4

Fwd: [proto][variant] variant crashes proto expression
by Igor R 11 May '16

11 May '16

The following code is a slightly modified Proto calc2 example. Instead of doubles I use variant<int, double>, and the expression is just _1 = _2. This code triggers assertion in variant/detail/forced_return.hpp, so it looks like some variant instance gets messed up. It happens when the value returned from proto::eval(*this, ctx) is being copied. It can be reproduced both with MSVC and gcc, with Boost 1.60. Is there any workaround for this issue? Thanks. ////////////// #include <iostream> #include <boost/proto/proto_typeof.hpp> #include <boost/proto/core.hpp> #include <boost/proto/context.hpp> #include <boost/variant.hpp> namespace proto = boost::proto; using proto::_; typedef boost::variant<int, double> var_t; template<typename Expr> struct calculator_expression; // Tell proto how to generate expressions in the calculator_domain struct calculator_domain : proto::domain<proto::generator<calculator_expression> > {}; // Will be used to define the placeholders _1 and _2 template<int I> struct placeholder {}; // Define a calculator context, for evaluating arithmetic expressions // (This is as before, in calc1.cpp) struct calculator_context : proto::callable_context< calculator_context const > { // The values bound to the placeholders var_t d[2]; // The result of evaluating arithmetic expressions typedef var_t result_type; explicit calculator_context(const var_t &d1 = var_t(), const var_t &d2 = var_t()) { d[0] = d1; d[1] = d2; } // Handle the evaluation of the placeholder terminals template<int I> result_type operator ()(proto::tag::terminal, placeholder<I>) const { return d[ I - 1 ]; } }; // Wrap all calculator expressions in this type, which defines // operator () to evaluate the expression. template<typename Expr> struct calculator_expression : proto::extends<Expr, calculator_expression<Expr>, calculator_domain> { explicit calculator_expression(Expr const &expr = Expr()) : calculator_expression::proto_extends(expr) {} BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression<Expr>) // Override operator () to evaluate the expression var_t operator ()() const { calculator_context const ctx; return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1) const { calculator_context const ctx(d1); return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1, const var_t &d2) const { calculator_context const ctx(d1, d2); return proto::eval(*this, ctx); } }; // Define some placeholders (notice they're wrapped in calculator_expression<>) calculator_expression<proto::terminal< placeholder< 1 > >::type> const _1; calculator_expression<proto::terminal< placeholder< 2 > >::type> const _2; // Now, our arithmetic expressions are immediately executable function objects: int main() { BOOST_PROTO_AUTO(expr, _1 = _2); var_t a1(1), a2(2.5); expr(a1, a2); return 0; }

1 0

openmpi with boost::log and some late endl
by Peter Vollmer 11 May '16

11 May '16

I'm working on some Linux systems and boost:log. More in detail: After replacing a handmade solution for logging with boost:log and running it with mpi on a single computer I can observe a strange behavior in console. Normally as i understand it, with autoflush turn on, after streaming a message into the logger it follows a flush followed by an endl and flush. At my scenario after streaming messages on different mpi processes, it seem that the system make a thread change right after flushing my message not after the endl flush. The missing automatic endl isn't lost it will be printed directly after or later but it will be printed. One indication that it has to be a thread change of the system is that an increase of the usable mpi processes increases the presents dramatically. For example on 4 core 8 thread system it occurs with 4 mpi processes something around 1 or 2 times, with 8 it occurs more than 20 times. Is there a solution to prevent this? Thanks Peter

1 0

[proto][spirit] parsing into proto expressions
by Igor R 11 May '16

11 May '16

Hi, Long story short: I would like to create proto expressions at run-time using spirit parsers. Would it be possible? More in details: I'd like to parse disassembler output, creating proto expression template for instruction and its operands. Lets assume we define proto expressions that would allow to express the following asm: "lea eax, [ebx + 2 * ecx]" like this: BOOST_PROTO_AUTO(lea_instr, eax = &*(ebx + 2 * ecx)); // registers and immediates are proto terminals Of course, we can't write such an expression in C++ code, because the actual operands get known after the asm string is parsed. So we can express any "lea" in the code (at compile-time) in a more general form, using placeholders: _1 = &_2; Then, when the parser matches "lea", we need to parse and create at run-time the actual operands, i.e. to substitute _1 with eax and _2 with *(ebx + 2 * ecx). I'd appreciate any pointer! Thanks.

2 2

mpfr_float stack allocation
by Daniel Brake 10 May '16

10 May '16

Hi Boost Users, I use Boost.Multiprecision's wrappers for MPFR, particularly the boost::multiprecision::mpfr_float. I've had good success with this library and its types so far, enjoying performance gains because of expression templates, and easy access to mpfr and gmp for floats, ints, and rationals. However, in my complex number type, I am struggling with named real temporaries in arithmetic operators. I am looking for help with multiplication, and I can generalize to all other operations needing a real temporary later. Here's my current code for multiplication, implemented in terms of *=. /** Complex multiplication. uses a single temporary variable 1 temporary, 4 multiplications */ complex& operator*=(const complex & rhs) { mpfr_float re_cache(real_*rhs.real_ - imag_*rhs.imag_); // cache the real part of the result imag_ = real_*rhs.imag_ + imag_*rhs.real_; real_ = re_cache; return *this; } I am using the naive evaluation formula, for better or worse. But the particular method of evaluation doesn't matter to me right now, it's the temporary variable re_cache used to cache the real part is killing me. Profiling using Allinea, gprof, and Callgrind reveals that a significant percentage of time in the program is consumed creating and destroying re_cache, as well as other temporaries scattered throughout my code. In an effort to eliminate heap allocations, I first tried replacing my using mpfr_float = boost::multiprecision::number<boost::multiprecision::mpfr_float_backend<0,boost::multiprecision::allocate_dynamic>, boost::multiprecision::et_off>; with allocate_stack, just for these named temporary variables. However, the documentation <http://www.boost.org/doc/libs/1_60_0/libs/multiprecision/doc/html/boost_mul…> states that allocate_stack only works in fixed precision, so the 0 digits indicating variable precision should cause problems? I expected 0 digits to fail to compile, but compile it does. The conversion from the type with allocate_stack to allocate_dynamic is not provided by the = operator, so I can write re_cache.convert_to<mpfr_float_dynamic>(). But using variable precision with stack allocation appears to cause all sorts of problems. Everything depending on complex multiplication in my program breaks, indicated by massive failures in my test suite. Thus, I currently regard allocate_stack as a non-solution. My question fundamentally regards how to deal with re_cache and the *= operator for complex multiplication. Anyone have ideas on how to get rid of constant heap de/allocation of re_cache without inducing a ton more arithmetic? Using a static for it is not a solution, both because I anticipate multithreading in this application in the future, and the fact that precision will vary though the run, so I'd have to check the precision of re_cache on every evaluation. The C version of the program I am re-implementing used OpenMP for threads, and used a thread-id-indexed global for re_cache. That solution then forces OpenMP onto anyone wanting to use the complex class in multiple threads. Hence, I view this as a non-solution, too. Again, my initial thought was 'heap allocation is the problem here, so I'll use the stack allocated backend'. But variable precision doesn't appear to work with allocate_stack. And statics are no good. Any thoughts? Thanks for your time, Daniel Brake Postdoc University of Notre Dame Applied and Computational Math and Stats

2 1

Re: [Boost-users] [boost] Boost 1.61.0 Release Candidate 2
by Marshall Clow 09 May '16

09 May '16

On Sat, May 7, 2016 at 4:31 AM, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > The second release candidates for the 1.61.0 release are now available at: > > http://boost.cowic.de/rc/boost_1_61_0_rc2.zip > http://boost.cowic.de/rc/boost_1_61_0_rc2.7z > http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.bz2 > http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.gz > > The SHA256 checksums are as follows: > > fa1c34862b7ba8674ed6e064a14667a11830c6252f702d9458451834b74f7815 > boost_1_61_0_rc2.7z > a547bd06c2fd9a71ba1d169d9cf0339da7ebf4753849a8f7d6fdb8feee99b640 > boost_1_61_0_rc2.tar.bz2 > a77c7cc660ec02704c6884fbb20c552d52d60a18f26573c9cee0788bf00ed7e6 > boost_1_61_0_rc2.tar.gz > 02d420e6908016d4ac74dfc712eec7d9616a7fc0da78b0a1b5b937536b2e01e8 > boost_1_61_0_rc2.zip > > The changes relative to RC1 are MSVC fixes for signals2 and graph > libraries. > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. > > I successfully built the .bz2 release with Apple's clang with C++03/11/14/1z. -- Marshall

1 0

Boost ASIO steady_timer and date change
by Sabino Colonna 09 May '16

09 May '16

Hello, I'm using a steady_timer to perform an asynchronous wait in the following manner: boost::asio::io_service io_service; boost::asio::steady_timer my_timer(io_service); void onTimeout(const boost::system::error_code& e) { // Print something } ... my_timer.expires_from_now(std::chrono::seconds(600)); my_timer.async_wait(onTimeout); io_service.run(); If system 'date' does not change, everything is ok. But if I change 'date' by hand while the timer is running, it expires before 600 seconds (more or less after 5 minutes) and 'onTimeout' is called. With synchronous wait, all is ok. According to documentation, steady_timer should not be affected by time change. Which may be the problem? Thanks, Sabino

2 2

Re: [Boost-users] Compiler limitation (MSVS 2015 update 2) or real error using boost::async?
by James Swift 06 May '16

06 May '16

Hi, in case anyone wants to play with the example I provided but doesn't have access to MSVC you can do so online here. http://rextester.com/BAX37541 kind regards, James

2 2