- Boost-users - lists.preview.boost.org

[logging+unittest]
by Witold E Wolski 19 Sep '14

19 Sep '14

Hi, I need to integrate some loggin into my unit to some extend bein integration tests (hardware). How best to call this function which sets up boost logging void init() { boost::log::add_file_log("sample.log"); boost::log::core::get()->set_filter ( boost::log::trivial::severity >= boost::log::trivial::info ); } if I have a test Runner looking like: #define BOOST_TEST_MODULE MasterTestSuite #include <boost/test/unit_test.hpp> Is there a way not have to add the suites manually Thanks. -- Witold Eryk Wolski

1 1

[thread] memory synchronization multiple mutexes
by firespot 19 Sep '14

19 Sep '14

Hi, How does memory synchronization and visibility behave when multiple mutexes are involved? I have two groups of threads (boost::thread_group) and two mutexes (boost::mutex m1, boost::mutex m2) + associated condition variables, with each thread group being responsible to write to some variables (here Ptr, run) and consistently using "its" mutex for locking. However there is a piece of code that looks - much simplified - like this: void f() { { boost::unique_lock<boost::mutex> Lock(m1); Ptr = someAddress; // set the Ptr from 0 to some memory address } { boost::unique_lock<boost::mutex> Lock(m2); run = 1; // was 0, inform that execution can proceed condVar2.notify_all(); } ... // wait until Ptr has been reset to 0 { boost::unique_lock<boost::mutex> Lock(m1); while (Ptr != 0) condVar1.wait(Lock); } } and another function: void g() { { boost::unique_lock<boost::mutex> Lock(m2); while (run == 0) condVar2.wait(Lock); } // run the execution, e.g. std::copy(Ptr, Ptr + 100, Target); // finally all finished, signal back that Ptr is not needed any more { boost::unique_lock<boost::mutex> Lock(m1); Ptr = 0; condVar1.notify_all(); } } f() is only invoked from a thread of the first group, and g() only from a thread of the second group. Whenever Ptr might get changes the first mutex (m1) and its associated condition-variable is used, and whenver run might get changed the second mutex and its associated conditional variable is used. The control flow guarantees that run is not set to 1 prior to Ptr being set, and thus in g() the "running" itself (here the std::copy) cannot commence earlier. However, what puzzles me now: I used a different mutex for setting Ptr and setting/checking run. Does this have any impact whatsoever on memory visibility across the threads in the two thread-groups? Specifically, is it always guaranteed that when g() continues its execution (because run == 1) that it must see the correct value of Ptr (a non-NULL value)? Or is it possible that it still sees 0 and I'd have to make a separate locking involving m1 to guarantee a proper read for Ptr as anything written under a lock of m1 is also only guaranteed to be later properly read if the locking also used m1? thanks!

2 1

[mpl] simple mpl::transform with placeholder?
by Andrew King 19 Sep '14

19 Sep '14

Hi, Lets say I have an mpl vector defined as : template <typename Traits> struct A { }; template <typename Traits> struct B { }; typedef mpl::vector<A<mpl::_>, B<mpl::_> > MyVec; struct MyTraits {}; How do I 'apply' or transform MyVec with MyTraits? ie. I want the mpl::vector ... boost::mpl::vector<A<MyTraits>, B<MyTraits>>; I realise I can do mpl::apply<A<mpl::_>, MyTraits> to get A<MyTraits> but I can't work out how to do the equivalent to the entire vector. mpl::transform seems like what I should be using. Transform seems to do apply internally, but I can't work out the syntax to do something like: using substituted = typename boost::mpl::transform<MyVec, boost::mpl::apply<boost::mpl<_>, MyTraits> >::type; (This isn't right!) It may be I am confused because inside the transform, boost::mpl::_1 is the item in the vector, not the 'inner' placeholder. Sorry if this is a basic question ... Regards, Andrew

1 0

[Thread] Read-write locks
by lfrfly＠icqmail.com 18 Sep '14

18 Sep '14

I'm trying to create a standard read/write lock using Boost Threads, and I'm having a bit of difficulty mapping the Boost concepts onto the usual ones. A read/write lock should have several states: Locked for reading (multiple threads may lock at once), locked for writing (only one thread may lock, and no threads may be locked for reading at the same time), and unlocked. Ideally it would be nice if an RWL which is locked for reading may temporarily upgrade to locked for writing, then return to the locked for reading state. Boost supports several relevant notions of locking: shared locking, upgrade locking, and exclusive locking. This to me is a confusing distinction. In particular, a shared_mutex seems appropriate as the basis for a RWL, but is lock_upgrade() the equivalent of a write lock and lock_shared the equivalent of a read lock? This is unclear. If "upgrade locking" is not the same as "exclusive locking", then is an upgrade lock actually exclusive? Could someone please clarify this.

4 3

Numeric Cast from integer to floating point
by dariomt＠gmail.com 17 Sep '14

17 Sep '14

Hi, Quoting the docs for boost::numeric_cast: "There are several situations where conversions are unsafe: [...] Conversions from floating point types to integral types." What about conversions from integral types to floating point types? E.g. from 64bit int to double. The following example shows what I mean: #include <iostream> #include <cmath> #include <boost/numeric/conversion/cast.hpp> int main() { const uint64_t i = 123445678911188878; std::cout << "i=" << i << std::endl; const double d = i; std::cout << "d=" << std::fixed << d << std::endl; std::cout << "next=" << std::fixed << std::nextafter(d, std::numeric_limits<double>::max() ) << std::endl; std::cout << "prev=" << std::fixed << std::nextafter(d, -std::numeric_limits<double>::max()) << std::endl; // I'd expect the following cast to fail const double dd = boost::numeric_cast<double>(i); std::cout <<"dd=" << std::fixed << dd << std::endl; return 0; } prints i=123445678911188878 d=123445678911188880.000000 next=123445678911188896.000000 prev=123445678911188864.000000 dd=123445678911188880.000000 because that integer cannot be represented in double precision Is there something in Boost to help here? Thanks in advance

5 4

value_type in Typed In Place Factory
by Adam Badura 17 Sep '14

17 Sep '14

According to header file boost/utility/typed_in_place_factory.hpp (as linked from documentation: http://www.boost.org/doc/libs/1_55_0/boost/utility/typed_in_place_factory.h…) typed_in_place_factory has member type value_type which is the constructed type. Yet documentation ( http://www.boost.org/doc/libs/1_55_0/libs/utility/in_place_factories.html) fails to mention it. Why? Is it not part of the interface (I would assume so based on not mentioning it in documentation...)? Or was it just forgotten? I find such value_type quite useful... And since I'm already writing let me note that the mentioned documentation has also another minor issue. In Specification section the sample in_place_factory and typed_in_place_factory should be named in_place_factory1 and typed_in_place_factory1. As this is how they are really named. Or it should be stated explicitly that the actual name is implementation dependent. Adam Badura

1 0

Boostlog and ASIO crash in shared library
by Ray Cheng 17 Sep '14

17 Sep '14

Hi, My project use a simple main using dlopen to "run" the real main function in target shared library. I use both Boost Log and ASIO (for threadpool) in the project. In Linux I found the ASIO got weird behavior with some un-initialized variables and crashing all the time. I am able to trim down my problem into a small program as below: // *** threadpool.cpp *** #include <iostream> #include <memory> #include <boost/asio/io_service.hpp> #include <boost/bind.hpp> #include <boost/thread/thread.hpp> void print() { std::cout << "print" << std::endl; } struct ThreadPool { void start() { boost::asio::io_service ioService; boost::thread_group threadpool; std::unique_ptr<boost::asio::io_service::work> work = std::make_unique<boost::asio::io_service::work>(ioService); threadpool.create_thread(boost::bind(&boost::asio::io_service::run, &ioService)); for (int i=0; i<100; ++i) { ioService.post(&print); } std::cout << "Post all calculation tasks" << std::endl; work.reset(); threadpool.join_all(); ioService.stop(); std::cout << "Finished all calculation tasks" << std::endl; } }; extern "C" void createthreadpool() { ThreadPool pool; pool.start(); } // *** threadpool.cpp *** g++ -O0 -std=gnu++1y -fPIC -c -g -DLinux -DGNU_GCC -I${BOOST_HOME}/include threadpool.cpp g++ -shared -o libthreadpool.so threadpool.o -L${BOOST_HOME}/lib -lboost_system -lboost_date_time -lboost_thread -lboost_filesystem -lboost_regex -lboost_chrono -ldl -lstdc++ // *** main.cpp *** #include <dlfcn.h> #include <iostream> int main(int argc, char** argv) { typedef void* createProcess(); auto service = dlopen("libthreadpool.so", RTLD_LAZY); createProcess* make = reinterpret_cast<createProcess*>(dlsym(service, "createthreadpool")); std::cout << "dlsym" << std::endl; make(); return 0; } // *** main.cpp *** g++ -O0 -std=gnu++1y -fPIC -c -g -DLinux -DGNU_GCC main.cpp // Link against boost_log to simulate my problem (although it is not using any boost_log). This version will crash g++ -o main.bad main.o -L${BOOST_HOME}/lib -lboost_system -lboost_date_time -lboost_thread -lboost_filesystem -lboost_regex -lboost_chrono -lboost_log -ldl -lstdc++ // it works fine If link against libthreadpool, surprising me g++ -o main main.o -L/home/sysmmbuild/dev/boost -lthreadpool -L${BOOST_HOME}/lib -lboost_system -lboost_date_time -lboost_thread -lboost_filesystem -lboost_regex -lboost_chrono -lboost_log -ldl -lstdc++ One more finding is, if compile boost_log without thread support, the main.bad also working fine. I have attached the code and make.sh as make script. Software version Redhat enterprise 6.5 g++ 4.9.1 Boost 1.56.0 Rgds, Ray

2 2

[Thread] thousands of spurious wakeups from timed_wait() per second
by Steven Clark 15 Sep '14

15 Sep '14

I've been trying to get useful behavior out of condition_variable::timed_wait() with little success. Depending on the platform, I'm getting about 3000 or nearly 100000 spurious wakeups per second. I'm working on a few different Linux platforms with different versions of Boost: 1.46, 1.48, and another in the high 40's. The eventual target is 1.48. I've looked for bug reports and haven't found any, and I have no evidence yet that suggests the different versions are significant to this problem. Because of the lack of problem reports, I figure I'm doing something wrong. That's my question: "What am I doing wrong here?" I have a test program that sets up a typical producer/consumer example. The main program spawns a thread, the producer, that notifies the main thread via a condition_variable once a second for a few seconds, then ends. The main thread, the consumer, waits efficiently for notifications with a 2-second timeout. When the producer thread finishes, the main (consumer) thread eventually times out, joins the spawned thread, and exits. At least, that's what is supposed to happen. If I don't bother with timeouts and use condition_variable::wait(), it works perfectly - except for the timeout, join, and exit. This is as expected. So far I have seen no spurious wakeups at all with this test. There is an ominous yet ambiguous remark in the documentation "The duration overload of timed_wait is difficult to use correctly. The overload taking a predicate should be preferred in most cases." Due to that remark I stopped experimenting with relative timeouts before I got anything to work. Using absolute timeouts, I get very high numbers of spurious wakeups as mentioned above - 3000 and about 100000 per second depending on the platform. I see no difference between timed_wait with a predicate and without a predicate. I'm also having trouble with the return value of timed_wait(). The documentation carefully states that timed_wait() returns "false if the call is returning because the time specified by abs_time was reached, true otherwise". This seems to mean that spurious wakeups return true -- and if you think about it, the return value is useless if spurious wakeups could return false. You'd have to add your own check for timeout. I was quite surprised to find that every spurious wakeup of timed_wait() that I've ever seen returns false. That just doesn't make sense to me. Here is the version of my test program that uses timed_wait without a predicate, followed by its output. #include <boost/thread.hpp> #include <boost/date_time.hpp> #include <iostream> boost::condition_variable gCond; boost::mutex gMutex; bool gGotData; unsigned gValue; void threadfn() { for (unsigned i = 0; i < 7; i++) { std::cerr << "hello from threadfn(), #" << i << std::endl; { boost::lock_guard<boost::mutex> guard(gMutex); gGotData = true; gValue = i; } gCond.notify_one(); boost::this_thread::sleep(boost::posix_time::seconds(1)); } } int main() { std::cerr << "******* Using timed_wait()" << std::endl; gGotData = false; gValue = 999; boost::thread t(threadfn); while (true) { boost::system_time deadline( boost::posix_time::microsec_clock::local_time()); std::cerr << "now is " << deadline << std::endl; deadline += boost::posix_time::seconds(2); std::cerr << "deadline is " << deadline << std::endl; boost::unique_lock<boost::mutex> lock(gMutex); unsigned nWakeups = 0; while(!gGotData) { bool ret = gCond.timed_wait(lock, deadline); nWakeups++; if (ret) std::cerr << "timed_wait() returned true on wakeup #" << nWakeups << std::endl; } std::cerr << "main() exited inner loop with " << nWakeups << " wakeups; gGotData is " << (gGotData ? "true" : "false") << std::endl; if (gGotData) { std::cerr << "main(), notified, gValue is " << gValue << std::endl; gGotData = false; } } // not reached in this incarnation of the code t.join(); std::cerr << "main(), after joining" << std::endl; } ******* Using timed_wait() now is 2014-Sep-09 20:48:12.183781 deadline is 2014-Sep-09 20:48:14.183781 hello from threadfn(), #0 timed_wait() returned true on wakeup #1451 main() exited inner loop with 1451 wakeups; gGotData is true main(), notified, gValue is 0 now is 2014-Sep-09 20:48:12.215471 deadline is 2014-Sep-09 20:48:14.215471 hello from threadfn(), #1 timed_wait() returned true on wakeup #96864 main() exited inner loop with 96864 wakeups; gGotData is true main(), notified, gValue is 1 now is 2014-Sep-09 20:48:13.216511 deadline is 2014-Sep-09 20:48:15.216511 hello from threadfn(), #2 timed_wait() returned true on wakeup #95911 main() exited inner loop with 95911 wakeups; gGotData is true main(), notified, gValue is 2 now is 2014-Sep-09 20:48:14.216805 deadline is 2014-Sep-09 20:48:16.216805 hello from threadfn(), #3 timed_wait() returned true on wakeup #97526 main() exited inner loop with 97526 wakeups; gGotData is true main(), notified, gValue is 3 now is 2014-Sep-09 20:48:15.217191 deadline is 2014-Sep-09 20:48:17.217191 hello from threadfn(), #4 timed_wait() returned true on wakeup #104710 main() exited inner loop with 104710 wakeups; gGotData is true main(), notified, gValue is 4 now is 2014-Sep-09 20:48:16.217453 deadline is 2014-Sep-09 20:48:18.217453 hello from threadfn(), #5 timed_wait() returned true on wakeup #102404 main() exited inner loop with 102404 wakeups; gGotData is true main(), notified, gValue is 5 now is 2014-Sep-09 20:48:17.217685 deadline is 2014-Sep-09 20:48:19.217685 hello from threadfn(), #6 timed_wait() returned true on wakeup #97906 main() exited inner loop with 97906 wakeups; gGotData is true main(), notified, gValue is 6 now is 2014-Sep-09 20:48:18.217291 deadline is 2014-Sep-09 20:48:20.217291 ^C Thank you very much, Steven Clark

4 9

[fusion] BOOST_FUSION_DEFINE_STRUCT with user defined methods
by Tobias Loew 15 Sep '14

15 Sep '14

Hi, I often use BOOST_FUSION_DEFINE_STRUCT not to generate a fusion-sequence per se, but to get a struct with - default initialisation for all members - a reasonable set of constructors - equality-check - all above without additional code But sometimes I would like to have additional methods in those structs, but deriving from those or fusion-adapting them loses at least one of the nice properties above. After looking at the BOOST_FUSION_DEFINE_STRUCT implementation I though about splitting the makro BOOST_FUSION_DEFINE_STRUCT_IMPL an inject my code in-between. Now my questions are: - Is there anything I've overseen and might detroy some fusion-mechanism? - Is there any chance to get macros like BOOST_FUSION_DEFINE_STRUCT_[BEGIN|END] (and also for the other BOOST_FUSION_DEFINE_... macros? Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/fusion-BOOST-FUSION-DEFINE-STRUCT-with-u… Sent from the Boost - Users mailing list archive at Nabble.com.

4 8

WG: [atomic] can it bechecked that boost::atomic<T> *v = reinterpret_cast<boost::atomic<T>*>(var); is safe?
by Tim Odenthal 15 Sep '14

15 Sep '14

On 15 Sep 2014, at 18:00, boost-users-request(a)lists.boost.org<mailto:boost-users-request@lists.boost.org> wrote: On Monday, September 15, 2014 07:31 PM, Tim Odenthal wrote: Dear experts, essentially, I use this type of reinterpret_cast for doubles, and it __seems__ to work fine. I compile-time check that the sizeof(boost::atomic<T>) == sizeof( T ), but is that enough to ensure that this will always work? Should/could I check alignment issues as well? Even if the "atomic_cast" function has a (small) run-time overhead, it would be very much worth it in my setting, where I actually want to safely add to a double at some location in memory. Obviously, I want to use boost::atomic to be system/compiler agnostic, since it's supposed to eventually run with clang, gcc, (linux, OS X) as well as MS compilers, and so far we didn't see the need to move to C++11... I'm not sure I can figure out what problem you're trying to solve. Well, essentially, I have an array of doubles that at exactly one point in the code needs to be added to where I cannot ensure that each thread only adds to its own part of the array, so I want to ensure that each addition there is executed atomically. I think the cast is probably "safe", but far less can be said of it when it's dereferenced. That would depend entirely on the type of var. Is *var actually a boost::atomic<T> in the first place? If it is, why are you erasing its type? No, as I was saying, it’s a double *. How can you be sure there is nobody else aliasing var or *var and then reading or writing it? That is actually a problem, but since I completely control that part of the code, I hope to not make that mistake ;-). If *var is not a boost::atomic<T>, reinterpret_cast isn't going to magically convert it, you have undefined behaviour. Of course, one effect of UB is that it __seems__ to work, until, presumably, it doesn’t. But what, then, is the difference between an atomic<double>* and a normal double*, if the sizes (and possibly alignments) are the same? Hmmm, I just read up on what a reinterpret_cast<> is supposed to be good for, which is very little indeed, so it seems that the behaviour is undefined - but then there is no way to solve that problem? (So far I only ever used it to print the address of a pointer...) Since openMP allows for a pragma atomic, somehow, it seems that there should be a way. Using a simple spin_lock is way too slow (tested), since it doesn’t lock a specific memory location, but essentially everything, and I suspect that more complicated locking schemes will be also more expensive, just for different reasons. Ben Thanks for your insight! Tim

2 1