September 2009 - Boost-users

Re: [Boost-users] shared_ptr and weak_ptr concurrency
by Jerry Jeremiah 08 Sep '09

08 Sep '09

Just to make sure I understand, am I right that this assumes x86/x64 CPUs and only those built in types up to register size (no 64 bit integers) and may not include single bytes in all circumstances? If you wrote code that depended on this assumption how could you be sure it wouldn't be ported to a box with a different CPU (I move stuff all the time between x86 and AIX, HPUX and sometimes a VAX). Can I make the same assumptions or not? And how can I be sure? Thanks, Jerry Message: 1 Date: Fri, 4 Sep 2009 11:58:46 -0400 From: John Dlugosz <JDlugosz(a)TradeStation.com> To: "boost-users(a)lists.boost.org" <boost-users(a)lists.boost.org> Subject: Re: [Boost-users] shared_ptr and weak_ptr concurrency Message-ID: <89030B4A18ECCD45978A3A6B639D1F240266A3F2C7(a)FL01EXMB01.trad.tradestation .com> Content-Type: text/plain; charset="utf-8" I know that on x86 and x64 architectures, assigning to or reading from any location up to the native general-purpose register size is atomic if the item in question is properly aligned for its size. That is, { a=b; in parallel with b=c; } will not read a partially-changed b, if b is declared in the normal manner. Reading oddly-aligned things out of a packed stream, or using pragmas to change the alignment options, may upset this. Furthermore, the cache is coherent among multiple CPUs or cores, even on a NUMA server. What you have to watch out for is when the compile actually issues the read or write, since it can us a register and save it back to memory much later, or re-arrange the requests. Furthermore, the chip queues requests to memory with reads having priority, so a write followed by a read needs special consideration. Assigning to a (non-volatile) char might do something ?interesting?. For example, if two separate char variables are declared, the compiler might keep them in registers and save them both out at the end with a single 16-bit write. The x86/x64 instruction set is conducive to that, but not to other cases. But in general an architecture might indeed merge separate variables to single larger register. The compiler might then re-save something that didn?t change, thus clobbering a change made on another thread. The current C++ standard does not address threads, so there is indeed no portable way to guarantee that. You have to encapsulate and implement for each architecture, and use compiler-specific extensions. It would be interesting to see a list of architectures noting whether or not primitive type reads and writes are atomic, at least verifying that they are even if there is nothing listed that doesn?t. I?m sure they would all have footnotes to that, as I described above for the one I?m familiar with. --John From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Kevin Kassil Sent: Friday, September 04, 2009 9:32 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] shared_ptr and weak_ptr concurrency Stefan, On Thu, Sep 3, 2009 at 2:30 AM, Stefan Strasser <strasser(a)uni-bremen.de<mailto:strasser@uni-bremen.de>> wrote: ... why would you even need a lock here? the shared_ptr doc says that you can expect the same thread safety from shared_ptr as you can from built-in types. you can use multiple-readers-single-writer without any locks on built-in types. You can? Is assigning to a char or a double guaranteed to be atomic? How can the compiler guarantee that? -- What if there is some architecture for which it's not a single instruction assignment? Kevi

2 1

shared_ptr and weak_ptr concurrency
by Rajeev Rao 08 Sep '09

08 Sep '09

This is the first time I'm using boost in a multi-threaded env (linux x86_64,gcc 4). This question may have been asked in other forms. However, from what I've been able to search (google) up, I could not get a crystal clear answer. I'm essentially trying to use the solution provided in this page. http://onlamp.com/pub/a/onlamp/2006/05/04/smart-pointers.html?page=5. >From the boost documentation, it appears that this could be an undefined operation as the global shared pointer is being read and written to by multiple threads. Is that correct ? In case the link fails or someone wants more details, please read on. I've got a n reader threads and 1 writer thread. initializion Thread : shared_ptr< MyClass > global_ptr(createNewObject()) ; WriterThread :global_ptr.reset( createNewObject()) ReaderThreads:weak_ptr<MyClass> local_weak_ptr (globally_ptr) ;... if(shared_ptr< MyClass > local_shared_ptr = local_weak_ptr.lock() ) { // using local_shared_ptr.} else { // recreate weak ptr from global ?} thanks. Rajeev

7 16

[signals2] tracking intrusively ref-counted object
by Igor R 08 Sep '09

08 Sep '09

Hello, In my project I've got intrusively ref.counted objects (particularly, ATL COM-objects), which listen to signals of some asynchronous subsystem. Currently, when these objects connect to the signals, they bind their own intrusive smart-ptrs to the slot functor, like this: // pseudo code Object::init() { asyncSubsystem_.onSignal_.connect(bind(&Object::handleSignal, intrusive_from_this...)); // ensure the slot wouldn't bound to a dead object } Of course, this implies that the object cannot "die" until it's explicitly disconnected from the signal, so when the user of my library wants to get rid of such an object, he must call one more function (say, obj->close()) before resetting his smart-ptr to the object -- which is not just inconvenient, but also threatens the exception safety of user's code. Now I'd like to eliminate the need for this additional "finalization". For this purpose I have to: a) bind plain "this" to the slot functor -- so that the signal wouldn't be a "strong" client of Object b) eliminate race condition between slot invocation (coming from asyncSubsystem's thread) and the destruction of Object caused by resetting of user's intrusive ptr I tried to think of different ways to solve (b), but nothing seems to work so far... So my question is whether (b) is ever possible, and what would be the right solution for the whole issue. Thank you, Igor'.

3 7

[Thread] finding a good expression to wait...
by Julien Claassen 08 Sep '09

08 Sep '09

Hello everyone! I'm trying to build a simple user-interface. It reads events from the keyboard using cin in one thread and then yields to a controller, which does some work. I'm doing the waiting part in the threads using condition_variables. The input-threads "main-function" looks something like this: *** CODE SNIPPET *** condition input_cond, output_cond; // some other code void main_loop(condition& in, condition& out) { char input_key; boost::mutex::scoped_lock lk(my_global_mutex); while (input_key != 'q') { while (in.timed_wait(lk,system_time(second_clock::local() + seconds(1)) \ == false) // DEFINITELY NOT! good { } cin >> input_key; out.notify_one(); } } *** END OF CODE *** The controller/output main_loop looks similar only it uses out.timed_wait(...) and in.notify_one(), when the crucial task is done. Result is, both main_loops, when passed to a thread start and then it's deadlocked. I have seen examples of the producer/consumer pattern, which worked with buffers and they used conditions like: while (buffer_full == 0) or similar. I only have one key, no queueing, so what to do here? Please any good pointer/help/example is appreciated. Gratefully yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

2 4

Exponential function
by amir ghanbari 08 Sep '09

08 Sep '09

Hi all, I'm new to boost and I wanted to know how can I compute exponential function in boost? thanx in advance!

2 1

[bind] and [function] : question on binding member function
by Moritz 08 Sep '09

08 Sep '09

Hi, can someone explain to me why the following code crashes at the third call to "a.call_func" when "str" is dereferenced? Should'nt it crash when "this" is dereferenced? Thanks in advance. typedef boost::function<void (void)> Callback; class A { public: void set_cb_func( Callback cb ) { callback = cb; } void call_func() { callback(); } Callback callback; }; class B { public: B() : str(new std::string) {} ~B() { delete str; } void do_sth() { std::cerr << &(*this) << " " << *str << std::endl; *str += "string"; }; std::string * str; }; int main() { A a; { B b; a.set_cb_func(boost::bind(&B::do_sth, &b)); a.call_func(); a.call_func(); } a.call_func(); return 0; }

3 2

[Accumulators] Matching via ADL.
by Robert Jones 08 Sep '09

08 Sep '09

In this code sequence: boost::accumulators::accumulator_set< long, boost::accumulators::features< boost::accumulators::tag::sum > > my_acc; long f( ) { using namespace boost::accumulators; return sum( my_acc ); } why do I need a using declaration? Shouldn't sum() be found via ADL? Using Boost 1.39 & MSVC 8. Thanks - Rob.

1 0

[serialization] Workarounds for serialization of std::map / non-default constructors
by Chard 08 Sep '09

08 Sep '09

When serializing a std::map (specifically, the loading part) if either the key or value type of the map's pair is not default constructable then workarounds are required (note: this has only been confirmed with the std::map implementation provided with MSVC71). E.g.: {{{ #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/serialization.hpp> #include <boost/serialization/map.hpp> #include <sstream> #include <utility> //////// // Example, non-default constructable class class X { public: X(int i) : i_(i) {} private: int i_; friend class boost::serialization::access; template <typename A> void serialize(A &ar, const unsigned) {} }; template <typename A> inline void load_construct_data(A &ar, X * a, const unsigned) { ::new(a)X(1); // e.g. } ////////////////////////////////////////// void test_ser_pair() { std::map<double, X> theMap; theMap.insert(std::make_pair(0.5, X(1))); std::string text; { std::ostringstream ostr; boost::archive::text_oarchive arch(ostr); arch & theMap; text = ostr.str(); } { std::istringstream istr(text); boost::archive::text_iarchive arch(istr); // Next line doesn't compile under MSVC7.1 because the serialization // of map uses the default constructor of std::pair. arch & theMap; } } }}} My current workaround is to provide a specialization of just the std::pair constructor for my map's pair, but it would be nice if the library could provide a workaround.

1 0

Re: [Boost-users] Trying to serialize observer pattern - both subject and observers with pionters
by Mikael Carlsson 08 Sep '09

08 Sep '09

Hi, > > I am using the observer pattern in a design and would like to make > > both subject and observers serializable. The subject hold a > base class > > pointer to the observes and the observers holds a base > class pointer > > to the subject. > > > > If I have understood the library correct I must register > the class for > > base class pointers in order to serialize the class pointer. > > Nope - you just have to indicate the base class for each class that > has one. I have included a small piece of code. It illustrates how I have interpreted the documentation. As you can see I use BOOST_CLASS_EXPORT (from what I read above, this is not needed). If I exclude the BOOST_CLASS_EXPORT I get "unregistered class" exception. If I include it, it appears to works but I get seg. fault during main exit (most likely a different problem related to my environment). I guess that I am using some parts of the library incorrect. > > This > > means that I must include the concrete subject in the concrete > > observers and vice versa. > > The means that I will run into circular dependencies. > > Nope C++ doesn't permit a circular derived/base class structure Understood, but I do not have a circular dependency between derived/base class, but with concrete observable(subject) and concrete observers. > > > > I guess that I am missing something here, the observer > pattern must be > > frequently used and be serialized. > > You're confusing the class structure which cannot be circular with a > seqence of pointers which can be circular. I guess you are right, I think I understand. > The library can handle circular pointer references with no problem. Understood (and agreed) / Mikael Carlsson

1 0

Trying to serialize observer pattern - both subject and observers with pionters
by Mikael Carlsson 08 Sep '09

08 Sep '09

Dear list, I am using the observer pattern in a design and would like to make both subject and observers serializable. The subject hold a base class pointer to the observes and the observers holds a base class pointer to the subject. If I have understood the library correct I must register the class for base class pointers in order to serialize the class pointer. This means that I must include the concrete subject in the concrete observers and vice versa. The means that I will run into circular dependencies. I guess that I am missing something here, the observer pattern must be frequently used and be serialized. Have anyone used the observer pattern and managed to serialize both observers and subject with pointers included. / Mikael

2 1