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

Solving a synch problem with the Boost::Thread library.
by luca 28 Dec '06

28 Dec '06

Hello all, I have a set of modules (ie classes, say the Module class and some Module derived classes) which calculate (or generate) data, and two different module instances could be connected together: one would use as input data the output of the other one. I have also a class which manages (say the ModulesManager class) the interconnections of those modules and it triggers the calculation of all the modules. The calculation is triggered in an worker boost::thread at a given rate (i.e. when the ModulesManager::trig () method is called). The modules have an internal state (upon which its calculation is based on), which could be changed by another thread calling some method of the Module class, say Module::setOffset(int offset). The problem is that I would like that any change to the internal state of any module happen not when the network of modules is being triggered by the ModulesManager, but it could be possible only between a call to trig() and its subsequent call. I would like to have a suggestion on how to modelize that in an elegant way. I thought about using something like the following: struct ModulesManager { ModulesManager::trig () { recursive_mutex::scoped_lock (*mutex); for (each Module mod) { mod->calculate (....); }//for } shared_ptr<recursive_mutex> ModulesManager::getMutex () const {return mutex;} } Then any thread could change the internal state of any Module just by using a code such as: AnyClassRunningInAnotherThread::setModuleXInternalState () { recursive_mutex::scoped_lock (*modulesManagerInstance->getMutex ()); moduleX->setOffset (newOffset); } Thanks in advance for any better proposal, Luca

1 0

Re: [Boost-users] help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

boost-users-bounces(a)lists.boost.org wrote: > Ok the mist is rasing ;-) > > There should be no problem mixing pthread and Boost.Thread. > I.e. your inherited lib can use pthread while your new code > can use Boost.Thread on the native API. I agree. But I have to deal with a great fear factor here. People think there will be a problem and the only way to deal with it is to (truthfully) say that everything is using the win32 port of pthreads. It is the only approach that will be accepted :-( > > But if on the other hand for whatever reason you want to take > the additional (IMHO unnecessary step) to build boost thread > on top of pthread you can. Here is how we go: > > Open the file BOOST_ROOT/libs/thread/build/threads.jam > Follow the instructions found there and set up your > environment variables accordingly. Excellent. This is exactly what I was looking for. Thanks very much, I will give this a try. > Again the whole mess isn't worth doing it. Technically, I agree. Politically......deep sigh....... The build is now in progress and it is time for me to go home and eat more mince pies :-) I will pick up on this again in the New Year. Many thanks again and Happy New Year! -Andrew Marlow ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

1 0

Re: [Boost-users] help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

boost-users-bounces(a)lists.boost.org wrote: > Andrew Marlow wrote: >>> 1) Building the boost library on top of pthread instead of native >>> WinThreads? >> >> Yes. Once the boost libs (and a few examples) have built ok I will >> then release these as prebuilts. > > Sorry this does not make sense to me, as this would imply > your project will be using the boost library: Boost.Thread. Yes it will. > So normally you wouldn't want to have them use the pthread > implementation in turn. Things are not normal here. My app has to use an in-house lib that was coded using pthreads. When that lib had to be available on windoze they did it by using the win32 port of pthreads. My app has to use this in-house lib, hence I have to link with the win32 port of pthreads. But I also want to do my own threading. I want to do it in a platform-independent way so I choose boost threads. > The only exception I can think of is > when you are doing some performance testing. Nope. > Usually the Boost.Thread on native windows API will be faster > than on top of pthreads, since there is one emulation layer less. Agreed. And if it was not for the in-house lib being built on the win32 port of pthreads then we would probably use boost threads throughout with a default build that uses the win32 api. But that is not an option. We do not want any apps to contain a mixture of win32 pthreads and win32 API threads. > >> I will have to do this for a number of versions of Visual Studio. >> Then for VC71 I will use the prebuilt boost lib to build my own >> project. It will be developed using the VC71 IDE but will be built >> overnight by a perl script that uses msdev in command line mode. >> This overnight job will not build boost, it will pick up the boost >> prebuilt. > > So I assume you are attempting to build the boost library? Yes, but I want to build it with a version of the win32 port of pthreads that lives in a special (non-std place). > If so, simply read the getting started from the boost > homepage and then precompiler your library, which basically > has to be done from the boost root directory: bjam > -s"TOOLS=vc-7_1" install which will install to C:\Boost directory by > default. (The above is for version 1.33, upcoming 1.34 is different. ) I don't think that works. I already tried it and it builds to the WIN32 API, not to the win32 port of pthreads that I have. > As an alternative you might also download the prebuilt binary > versions of the lib. I thought of that, but that won't work either. The boost that I wind up with MUST be one that is built wrt the win32 port of pthreads that comes with this in-house lib. Even if there was a prebuilt version of boost built with the win32 port of pthread even that would not do. It must be the particular version of the win32 port of pthreads that the in-house lib was built with. Wot a pain, eh? -Andrew M. ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

2 1

Re: [Boost-users] help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

boost-users-bounces(a)lists.boost.org wrote: > Andrew Marlow wrote: >> I am trying to build boost 1.33.1 on Windoze using Visual Studio .NET >> 2003 (aka vc71). This seems to be build just fine using the default >> settings (bjam -sTOOLS=vc-7_1) but I need to do the build such that a >> win32 port of pthreads can be picked up. >> I need some help with this please. > > What do you want to achieve? > > 1) Building the boost library on top of pthread instead of > native WinThreads? Yes. Once the boost libs (and a few examples) have built ok I will then release these as prebuilts. I will have to do this for a number of versions of Visual Studio. Then for VC71 I will use the prebuilt boost lib to build my own project. It will be developed using the VC71 IDE but will be built overnight by a perl script that uses msdev in command line mode. This overnight job will not build boost, it will pick up the boost prebuilt. > Please try to precise as possible, describing what you are > trying to do, since there are a lot of possible scenarios to > use the boost libraries. Hopefully this is a bit clearer now.... -Andrew ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

2 1

help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

I am trying to build boost 1.33.1 on Windoze using Visual Studio .NET 2003 (aka vc71). This seems to be build just fine using the default settings (bjam -sTOOLS=vc-7_1) but I need to do the build such that a win32 port of pthreads can be picked up. I need some help with this please. Eventually I hacked boost/config/platform/win32.hpp, and added "#define BOOST_HAS_PTHREADS". Is this what we are expected to do? I could find no help in this particular area of configuration. This hack does indeed make it try to #include <pthread.h> but I don't know how to tell the build where to look for this header. Hence, I now get loads of compilation errors. My app uses a proprietary library that is built on the win32 port of pthreads. So in order for my app to use boost I need it to work with the win32 port of pthreads that the proprietary library was built with. This means picking up pthread.h from the proprietary library source directory, rather than picking it up from std places. How is this done please? Regards, Andrew Marlow ---- There is an emerald here the size of a plover's egg! Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

2 1

fail to pick up win32 port of pthreads lib at link time
by Andrew Marlow 28 Dec '06

28 Dec '06

I am still stuck on building boost with the win32 port of pthreads. After hacking win32.h to turn on pthreads I hacked msvc-tools.jam, adding an include option to the compilers command line, telling it in which directory pthread.h may be found. So now it all compiles. But it fails to link. I do not know enough about how boost jam works to be able to do a similar tweak to the linkers command line. And I am very uneasy at having to do these sorts of hacks. Surely there must be a better way. Can anyone help please? Regards, Andrew Marlow ---- There is an emerald here the size of a plover's egg! Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

1 0

[Multi-Index] find returning false positives?
by David Brownell 28 Dec '06

28 Dec '06

When comparing the results of the find method to the end iterator in the code below, it appears that find is finding elements that are not in the container. Am I using multi-index in the wrong way? Thanks for the help! #include <boost/multi_index_container.hpp> #include <boost/multi_index/sequenced_index.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/shared_ptr.hpp> #include <iostream> struct MyObject : private boost::noncopyable { explicit MyObject(int i) : _i(i) {} int Get(void) const { return(_i); } bool operator <(MyObject const &rhs) const { return(_i < rhs._i); } private: int _i; }; typedef boost::shared_ptr<MyObject> MyObjectPtr; using namespace boost::multi_index; typedef multi_index_container<MyObjectPtr, indexed_by<sequenced<>, ordered_unique<identity<MyObject> > > > MyContainer; struct CompareFunc { bool operator()(MyObject const &o, int i) const { return(i == o.Get()); } bool operator()(int i, MyObject const &o) const { return(o.Get() == i); } }; int main(void) { MyContainer c; c.push_back(boost::shared_ptr<MyObject>(new MyObject(3))); c.push_back(boost::shared_ptr<MyObject>(new MyObject(4))); c.push_back(boost::shared_ptr<MyObject>(new MyObject(1))); MyContainer::nth_index<1>::type const & r = c.get<1>(); std::cout << (r.find(1, CompareFunc()) == r.end() ? "Not found" : "found") << "\n"; std::cout << (r.find(13, CompareFunc()) == r.end() ? "Not found" : "found") << "\n"; // This should not be found return(0); }

2 1

[Boost.Threads] Exiting Thread Properly
by Soren Dreijer 28 Dec '06

28 Dec '06

Hi, I'm new to Boost.Threads and have previously been using Windows events to signal threads to shut down. Since the Boost.Threads library does not include an Event type I'm wondering what the best approach is to signal a thread to exit. Let's say the thread is a worker thread which loops around every time it has finished its job and then wants to determine if it should shut down or not. Thanks, Soren

4 6

Boost::Timer does not tick
by Christoph 27 Dec '06

27 Dec '06

I've tried to use Boost::Timer together with Qt. However, the elapsed() function always does return the same value. I've found hints (see http://www.gerd-riesselmann.net/development/std-clock-threading-and-linux) that this might be related to the threading (used in Qt4). Is this a known issue? What is the suggested workaround (apart from using something else for timing? Best regards Christoph

2 1

Re: [Boost-users] [Boost.Threads] Exiting Thread Properly
by Søren Dreijer 27 Dec '06

27 Dec '06

Ah, excellent! I seem to recall a post somewhere mentioning that relying on volatile might not always work on multiprocessor systems. Is that something to worry about?Quick follow-up question: Why do you use auto_ptr<bool> when passing the flag_guard to the thread when you release it right afterwards? Is there a chance that thread's constructor or bind() might throw an exception?Thanks for the quick response, Soren > Date: Wed, 27 Dec 2006 20:45:40 +0100> From: sebastian.redl(a)getdesigned.at> To: boost-users(a)lists.boost.org> Subject: Re: [Boost-users] [Boost.Threads] Exiting Thread Properly> > Soren Dreijer wrote:> > I'm wondering what the best approach is to signal a> > thread to exit.> Just allocate a boolean variable for each thread and pass the address to> the thread starting function. The loop of the thread breaks if the flag> is reset; the thread exits. This scheme is so simple that it doesn't> even require synchronization beyond making the pointer the thread> accesses volatile.> You could use a shared_ptr to manage the memory, but personally I would> simply use a scoped_ptr in the thread's main function.> The following code is conceptual. I can't remember the exact API of> Boost.Threads.> > void thread_proc(volatile bool *flag)> {> scoped_ptr<bool> guard(flag);> while(*flag) {> // Work> }> }> > map<threadid, bool *> flags;> > void create_worker()> {> auto_ptr<bool> flag_guard(new bool(true));> thread t(bind(&thread_proc, flag_guard.get()));> // Thread is started. This ensures that it will release the memory.> bool *b = flag_guard.release();> > flags.insert(make_pair(t.get_id(), b));> }> > // Note: this function needs to synchronize if you can't ensure that it> will only be ever called once> // for any given thread id.> void signal_worker(threadid id)> {> flag_iterator i = flags.find(id);> if(i != flags.end()) {> bool *b = i->second;> flags.remove(id);> *b = false;> }> }> > You will need to synchronize map access, of course.> > Sebastian Redl> _______________________________________________> Boost-users mailing list> Boost-users(a)lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users _________________________________________________________________ Call friends with PC-to-PC calling -- FREE http://get.live.com/messenger/overview

2 1