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

Re: [Boost-users] [Wave] effect of allocation of data structures oncopying data structures
by Hartmut Kaiser 12 May '06

12 May '06

> Andreas Sæbjørnsen wrote: > > > I need some advice regarding how I should copy the boost data > > structures I get from 'advanced_preprocessing_hooks.h'. > > The task at hand is to copy some of the data structures > from Wave and > > store it separate form the memory Wave allocates so that after the > > Wave preprocessing step has finished all it's memory can be freed. > > > > Example: e.g making a copy of the > > 'std::vector<std::list<PreprocessingInfo::token_type,boost::fa > > st_pool_allocator<PreprocessingInfo::token_type> > >' > > representing the arguments in the expansion of a macro in > the function > > 'expanding_function_like_macro'. > > > > Syntactically it would be gre at to be able to make a copy > using the > > operator=, but as far as I can see this is only possible if > I am also > > using the fast_pool_allocator. If I use the > fast_pool_allocator I am > > afraid that my copies will be put into the memory pool allocated by > > Wave and therefore that memory cannot be safely freed. Is > this corect? > > I'm not sure here. My (unverified) guess is, that the memory > pool will be free'd only after the last item allocated from > it got free'd. This shouldn't be a problem as long as the > memory pool doesn't live in a shared library which gets > unloaded prematurely. After looking at the code and the docs again I discovered the following: the boost::fast_pool_allocator is build on top of a thread local singleton pool. This pool gets allocated before entering main and gets free'd after main exits. Same should be true for shared libraries. So yes, you're running into problems only: 1) if you have your Wave application compiled into a shared library and 2) if you use data from the allocator used by Wave in a different module after the first shared library was explicitely unloaded from memory. HTH Regards Hartmut > But anyway, doesn't using std::copy() for the embedded > list<>'s allow to change to any adequate data structure? > > Regards Hartmut >

2 3

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 11 May '06

11 May '06

Hi Kobi, I am using ACE_Mutex. Let me check ACE Guards (I know there is ACE_Guard class), Is that what you mean? Thanks Priyank ________________________________ From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Kobi Cohen-Arazi Sent: Thursday, May 11, 2006 11:09 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [multi_index] Core dump in multi-index library !! Procedure * Procedure_Pool::find_by_id(int _id) { LD_TRACE("Procedure_Pool::find_by_id"); mutex_.acquire(); Procedure_By_Id::iterator it = procedure_by_id_.find(_id); if (it != procedure_by_id_.end()) { ACE_DEBUG((LM_DEBUG, "%N:%l Found procedure for id: %d \n", _id)); mutex_.release(); return *it; } ACE_DEBUG((LM_DEBUG, "%N:%l Not able to found procedure for id: %d \n", _id)); mutex_.release(); // return null return 0; } BTW, As a side note, I highly recommend you to use ACE Guards (RAII...) for the mutex thing. Kobi

2 1

MPL/Fusion
by Sohail Somani 11 May '06

11 May '06

Hi, I am quite interested in MPL/Fusion. I have made my own toy projects using template metaprogramming to make decisions at compile time. I am interested in learning what types of software boost users create with it. Would anyone care to share? Thanks! Sohail

3 2

Re: [Boost-users] [multi_index] thread safety
by JOAQUIN LOPEZ MU?Z 11 May '06

11 May '06

----- Mensaje original ----- De: george <george13p(a)yahoo.com> Fecha: Jueves, Mayo 11, 2006 7:27 pm Asunto: Re: [Boost-users] [multi_index] thread safety > hello Joaquin Hello George, > > > You have to lockguard every access to the container; note this > > also includes, for instance, container traversal with iterators, > > i.e. iterator displacement. Strictly speaking, iterator dereference > > should also be lockguarded, although I can say unofficially that > > unguarded dereference is OK. > > can you explain a litle more? > as I konw from STL, multiple readers is ok. Correct. > reading and inserting a new object does't invalidate iterators(for > pointer-based > conteiners offcourse,list, map etc...) Correct. This also holds for multi_index_containers. > > a concurrent read and insert in multi_index are not > (safely)possible? I mean there might be an iterator > invalidation? Concurrent reading and writing is not safe, but the issue has nothing to do with iterator invalidation. ...I think I've got a hunch about what you've got in mind. When I say that you've got to lockguard iterator displacement, what I mean is: consider a concurrent write operation and an iterator increment; this concurrency is not thread safe and undefined behavior results: a possible outcome is iterator invalidation, but you could also get an app crash, a corrupted data structure, an infinite loop or whatever. Tecnhically speaking, an invalid iterator is a perfectly legal state for an iterator to be in, which has nothing to do with undefined behavior resulting from violating thread safety guarantees. I'm not sure I made myself clear :) Insist on me if I didn't. > offcourse there is a chance for a 'dirty-read' but this for the > domain of the aplication if it is a problem and not for multi_index. I don't get what you mean here, would you care to elaborate? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] [multi_index] thread safety
by Joaquín Mª López Muñoz 11 May '06

11 May '06

Conway Allen ha escrito: > Regarding thread safety, if threads are concurrently reading, > inserting, and erasing entries in a multi-index container do you have to > lockguard all of these operations or can you get away with just > lockguarding the inserts and the deletes? You have to lockguard every access to the container; note this also includes, for instance, container traversal with iterators, i.e. iterator displacement. Strictly speaking, iterator dereference should also be lockguarded, although I can say unofficially that unguarded dereference is OK. The kind of thread-safety provided by B.MI (and by most STL implementations) is described at SGI docs: http://www.sgi.com/tech/stl/thread_safety.html > Thanks, Allen. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 11 May '06

11 May '06

Hi Joaquin, I have put some locks in code and follows is the changed code. Also, I have removed API that takes procedure pointer. Instead it just takes id as input. Anyways, It seems to be working GREAT. Thanks for all your help. Will contact you incase of any problems. #include "../include/Procedure_Pool.h" int Procedure_Pool::add_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::add_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "ADDING %d\n", _procedure->id())); if (find_by_id(_procedure->id()) == 0) { // procedure not found mutex_.acquire(); procedure_by_id_.insert(_procedure); mutex_.release(); // debug info ACE_DEBUG((LM_DEBUG, "Added procedure : %d \n", _procedure->id())); // return success return 0; } else { // error ACE_ERROR((LD_ERROR "%N:%l Error in adding procedure : %d \n", _procedure->id())); // return failure return -1; } } int Procedure_Pool::remove_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::remove_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "REMOVING: %d \n", _procedure->id())); if (find_by_id(_procedure->id()) != 0) { // procedure found mutex_.acquire(); procedure_by_id_.erase(_procedure->id()); mutex_.release(); ACE_DEBUG((LM_DEBUG, "Removed procedure : %d \n", _procedure->id())); return 0; } else { ACE_ERROR((LD_ERROR "%N:%l Error in removing procedure : %d \n", _procedure->id())); return -1; } } Procedure * Procedure_Pool::find_by_id(int _id) { LD_TRACE("Procedure_Pool::find_by_id"); mutex_.acquire(); Procedure_By_Id::iterator it = procedure_by_id_.find(_id); if (it != procedure_by_id_.end()) { ACE_DEBUG((LM_DEBUG, "%N:%l Found procedure for id: %d \n", _id)); mutex_.release(); return *it; } ACE_DEBUG((LM_DEBUG, "%N:%l Not able to found procedure for id: %d \n", _id)); mutex_.release(); // return null return 0; } Thanks, Priyank -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of JOAQUIN LOPEZ MU?Z Sent: Wednesday, May 10, 2006 4:36 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [multi_index] Core dump in multi-index library !! ----- Mensaje original ----- De: Patel Priyank-PPATEL1 <priyankpatel(a)motorola.com> Fecha: Miércoles, Mayo 10, 2006 10:49 pm Asunto: Re: [Boost-users] [multi_index] Core dump in multi-index library !! > Hi Joaquin, [...] > One other thing, addition and deletionIs done by separate threads in > my application. Oh, oh. multi_index_container is *not* thread safe, so this smells like the problem --and it is not, it certainly has the potential to crash your app sooner or later. Please take into account thread unsafety extends to every member function of multi_index_container, so you'd better lockguard *every* public method of Procedure_Pool. Looking fwd to knowing your results. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo In case you're wondering, STL implementations typically have the same level of thread safety as B.MI provides: 1. Concurrent access to different containers is safe. 2. Concurrent read-only access to the same container is safe. The rationale is that locking every public method of an STL container adds an unavoidable runtime overhead (you might not need it), and moreover it doesn't necessarily map to what constitutes *atomicity* to a given app --in your case, for instance, atomicity, and thus lockguarding, is best done at the level of Procedue_Pool interface. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2

[BGL]: Highest performance graph-type available?
by Greg Link 11 May '06

11 May '06

I'm using BGL for the johnson_all_pairs_shortest_path algorithm, and spending about 98% of my runtime in that algorithm. Breaking it down, the BFS_visit itself is consuming some 85% of my total runtime. Hence, any and every improvement I can get in my BGL performance will make my app much much snappier. Currently, my graph type is a adjacency_list <vecS, vecS, undirectedS, no_property, property <edge_weight_t, double> > and I'm wondering if that's the best choice. My graph has (E=2*V), and all nodes are of constant degree, with 4 edges incident on them. V is usually in the range of 150-500. Would one of the other types (such as listS) perhaps be faster, and still work? I know some BGL algorithms require certain graph storage types, so I'm hesitant to just start poking around and trying random things. That, and other than "listS", I don't know of any other types of graph, as I'm quite new to both the BGL and boost in general. Any thoughts on what might make things faster? Additionally, are there any compiler flags I should consider other than the 'vanilla' ones? (-O3). I'm using GCC 4.0.1 currently, if it matters. Thanks for the great library, and such a friendly list, Greg Link

4 5

Problem with lambda expressions and uint64_t
by Olatunde Adonai 11 May '06

11 May '06

The following code compiles with f as a uint32_t. It does not compile with f as a uint64_t. Why is this? What can be done? #include <iostream> #include <algorithm> #include <boost/lambda/lambda.hpp> using std::cout; using std::for_each; using namespace boost::lambda; int main(int argc, const char* argv[]) { const char s[] = "abcdefghi"; //Problem: uint64_t f = 0xaa; //This compiles as a uint32_t. unsigned int i = 0; for_each(s , &s[sizeof(s) - 1] , cout << _1 << " = " << var(i)++ << " (" << ( ( f >> var(i) ) & 1 ) << ")\n" ); return 0; } __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

boost::iostreams regex_filter crash
by Andrew McDonald 11 May '06

11 May '06

I am using boost_1_33_1, in Microsoft Visual C++ 2005 Express Edition version 8.0.50727.42. Boost has been built with the vc-8_0 toolset. When using a filtering_stream with a regex_filter I get a crash in cases where the filtering_stream is destroyed (i.e. closed) having processed text without any match for the regex. =========================================================== #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/regex.hpp> #include <iostream> using namespace boost; using namespace boost::iostreams; // replaces y with Q const regex_filter Y_FILTER ( regex("y") ,"Q" ); // replaces x with Q const regex_filter X_FILTER ( regex("x") ,"Q" ); // test data has a y but no x const char* Y_BUT_NO_X = "abc y cba"; void test() { // outputs "abc Q cba" as expected { filtering_ostream out( Y_FILTER ); out.push(std::cout); out << Y_BUT_NO_X; } // crashes with null pointer dereference !!! { filtering_ostream out( X_FILTER ); out.push(std::cout); out << Y_BUT_NO_X; } } =========================================================== Please note that the same crash occurs with "real world" regex's and data so the issue is not caused by boundary conditions due to the "artificial" test data. It is generically caused by the condition of not matching the regex. The crash occurs at line 53 of boost/iostreams/filter/regex.hpp in the function void do_filter(const vector_type& src, vector_type& dest) { typedef regex_iterator<const Ch*, Ch, Tr> iterator; if (src.empty()) return; iterator first(&src[0], &src[0] + src.size(), re_, flags_); iterator last; const Ch* suffix = 0; // Prevent GCC 2.95 warning. for (; first != last; ++first) { dest.insert( dest.end(), first->prefix().first, first->prefix().second ); string_type replacement = replace_(*first); dest.insert( dest.end(), replacement.begin(), replacement.end() ); suffix = first->suffix().first; } dest.insert(dest.end(), suffix, &src[0] + src.size()); <<< Crash !! } In cases where no regex match will occur then first == last, the for loop body is never run and consequently suffix remains initialised to 0. Consequently its use in the line succeeding the loop body causes a crash. The intent of this last line is to copy any text remaining after the last match from the src to the dest. This means that an appropriate initialiser for suffix is the start of the src, so that all text is copied to the destination if no match occurs. This can be achieved by altering the line; const Ch* suffix = 0; // Prevent GCC 2.95 warning. to const Ch* suffix = &src[0]; // Prevent GCC 2.95 warning. However a small rewrite avoids several calls to operator[] and size() and makes the code (ever so slightly) more readable; void do_filter(const vector_type& src, vector_type& dest) { typedef regex_iterator<const Ch*, Ch, Tr> iterator; if (src.empty()) return; const Ch* start = &src[0]; const Ch* end = start + src.size(); const Ch* suffix = start; // Prevent GCC 2.95 warning. iterator first(start, end, re_, flags_); iterator last; for (; first != last; ++first) { dest.insert( dest.end(), first->prefix().first, first->prefix().second ); string_type replacement = replace_(*first); dest.insert( dest.end(), replacement.begin(), replacement.end() ); suffix = first->suffix().first; } dest.insert(dest.end(), suffix, end); } I have tested this with both the test() function above and my original data and correct output is produced. regards, Andrew Andrew McDonald System Architect > Norwood Systems Australia Pty Ltd Level 1, 71 Troy Terrace PO Box 1281 Subiaco, WA 6904 > Tel +61 8 9380 7766 > Fax +61 8 9380 7733 andrew.mcdonald(a)norwoodsystems.com > > The information in this email, and any attachments, may contain confidential information and is intended solely for the attention and use of the named addressee (s). It must not be disclosed to any person(s) without authorization. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain this message or any part of it. If you have received this communication in error, please notify the sender immediately. > > > > > > > > > > > > >

1 0

Re: [Boost-users] Compiling boost on Sol 5.2 compiler
by paul.floyd 11 May '06

11 May '06

> Hi, > > I am trying to use boost with Solaris 5.2 compiler. I am getting a compiler > error as a result of the macor BOOST_AUX_NTTP_DECL not being defined > anywhere. I would appreciate it very much if anyone could point me how I can > get past this stage. You won't get very far with Forte 6 update 1 (it is old, and no longer supported). I would suggest that you get either Studio 10 (available for free via opensolaris.org) or Studio 11 (available for free from Sun). At least, if you can't switch to either of those versions of Sun Studio, I'd consider trying to get Forte 6 update 2. This is a bit less old, and was supported up till about 6 months ago, and it should work OK with the same licence as Forte 6u1. However, it's still too old to compile fairly major chunks of Boost. Next take a look at http://blogs.sun.com/roller/page/sga This should get you much closer to being able to use most of Boost. A+ Paul Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34 /mn) ; tél : 08 92 68 13 50 (0,34/mn)

1 0