- Boost - lists.boost.org

Re: [boost] [Boost.smart_ptr] Thread Safety
by Thomas Jordan 08 Jan '12

08 Jan '12

Message: 7 Date: Sat, 07 Jan 2012 16:49:07 -0500 From: Dave Abrahams <dave(a)boostpro.com> To: boost(a)lists.boost.org Subject: Re: [boost] [Boost.smart_ptr] Thread Safety Message-ID: <m24nw7p4j0.fsf(a)pluto.luannocracy.com> Content-Type: text/plain >on Sat Jan 07 2012, "Thomas Jordan" <thomasjordan-AT-btinternet.com> wrote: >> Hi, >> Is shared_array completely thread-safe, including >> destruction/reference counting? From the code in >> /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but >> according to >> >> http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… >I can't reach that (very ancient) page right now, but... The documentation for this is example is the same in the latest v1.48 release. >> // thread A >> p3 = p2; // reads p2, writes p3 >> >> // thread B >> // p2 goes out of scope: undefined, the destructor is considered a "write >> access" >> >> shared_ptr isn't completely thread-safe for simultaneous read and >> write/destruct access? The same would presumbly apply to shared_array? >> Maybe I've missed something, are there compile-time configuration >> options to determine level of safety? >shared_ptr<T> is almost exactly as threadsafe as T* is. In this case, >thread A has a reference to an object on B's stack. That object is >called p2. If thread A tries to use that object's value while the >object is being destroyed, yeah, that's a race condition. >The way to avoid this situation is for thread B to pass p2 to thread A >by value, thus creating p2a, which thread A can read without concern. >Now there's no race condition. Note: this change does /not/ cause the T >object held by p2 to be copied. Thanks, I think my confusion arose from my inferring that the P2 in thread A in this example was shorthand for P2a, i.e., a copy of the actual P2 in thread B. Makes sense as per your interpretation. Regards, T.

1 0

[Boost.Poly] Runtime Concepts
by Thomas Jordan 08 Jan '12

08 Jan '12

Hi, Forgive me if this post strays into territory beyond Boost, but I was looking at the Adobe library http://stlab.adobe.com/group__poly__related.html and some of the research papers by Sean Parent et al. describing it, which I guess many people on this list will be familiar with. Is there any reason why this library/something akin has not been put into Boost? Is it simply that it will always live in Adobe Source Libraries and there is no point duplicating in Boost? Second question - the research papers on this seemed to peter out around 2009, is there any further work going on, or has this approach been taken as far as deemed interesting, or even been informally deprecated in favour of something else? Regards, T.

4 3

[Boost.smart_ptr] Thread Safety
by Thomas Jordan 07 Jan '12

07 Jan '12

Sorry, please ignore my previous post - finger trouble. The question is as follows: ------ Hi, Is shared_array completely thread-safe, including destruction/reference counting? From the code in /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but according to http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" shared_ptr isn't completely thread-safe for simultaneous read and write/destruct access? The same would presumbly apply to shared_array? Maybe I've missed something, are there compile-time configuration options to determine level of safety? Regards, T.

2 1

[Boost.Move] [Boost.Container] Compiling with older version of Boost and performance
by Thomas Jordan 07 Jan '12

07 Jan '12

Hi, I am interested in experimenting with v1.48 Boost.Move and Boost.Container. However, I am otherwise constrained to using Boost libraries v1.33.1 with a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library dependencies' listed in the Move/Container documentation, but a quick look through the header files suggests that it is mainly MPL and Type Traits. So... First question: would it be feasible for me to combine the headers for these two libraries with the v1.33.1 libraries and get it to work (albeit maybe with a little customisation), or would it be a big job/non-starter? Second question - I don't see any performance analysis published for Boost.Move. I know that move semantics is about more than improved performance, but am interested in that side of things, especially as the above compiler appears suboptimal in terms of copy elision and RVO. I am wondering for example whether are there any (compiler-specific) factors which could mitigate against the performance benefits of doing a move vs a copy of a vector, using these libraries, for example. Regards, T.

2 1

[Boost.smart_ptr] Thread Safety
by Thomas Jordan 07 Jan '12

07 Jan '12

Hi, Is shared_array completely thread-safe. including destruction/reference counting? http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" /bb/source/boost/boost_1_33_1/boost/detail/sp_counted_base_pt.hpp

1 0

On the lack of manpower: (Apache stdcxx)
by Jim Bell 06 Jan '12

06 Jan '12

Though this isn't news, I just came across it and it speaks to our common problem. (And it's of interest to boost users in general.) Note that ARM and Sun are even invested in stdcxx to some extent. From Apache's C++ Standard Library project <http://stdcxx.apache.org/status/2011-02.txt>: Stdcxx continues to be dormant. All but [1] committer have moved on to other projects. The only remaining committer (the VP of the project) is too busy with his day job to make even small changes, or to put out the long-awaited patch release, stdcxx 4.2.2. A number of users and organizations have been using the project and expressed interest in contributing to it. Several submitted patches, others have offered help with the project build and test infrastructure. Unfortunately, since no committer is available to review patches and guide the contributors through the ASF process to enable them to gain commit privileges there seems to be little hope of reviving stdcxx. A possible solution that would allow contributions to resume is to grant commit privileges to the handful of contributors who have already submitted some patches or expressed serious interest in contributing going forward. Another alternative is to move stdcxx to a repository outside of ASF such as SPI (http://www.spi-inc.org/) where interested developers could start committing changes on their own right away, without going through the "training" process. This seems to the preferred solution among at least some of the interested users. Are there any other options? Future plans: Unless the issue with contributions can be resolved in the next quarter I suggest to retire the project.

5 6

[Boost.Lambda] Some new features are suggested: return, iterating yield, & local var
by Huang Huan 06 Jan '12

06 Jan '12

Hi boosters, I'm intrested in Lambda, so I have worked out some new features, and suggest boost lib add them. What can I do next? NEW features: 1. return. why lambda lib do not include this? 2. generate iterator/iteration by lambda using yield return/yield break. 3. local/global var declare and using. 1. return e.g. boost::function<char(int)> f = ( if_ ( _1 >= 0 ) [ return_('a') ], return_('b') ); p.s. return should be supported. 2. iterator/iteration generation by lambda using yield return/yield break const char* p; // we shuld use the local var inside lambda instead of this var p. refer to section 3 iteration<char> it = ( for_(var(p) = _1, *var(p), var(p)++) [ if_(*var(p) != ' ') [ yield_return(*var(p)) ] if_(*var(p) == ';') [ yield_break() ] ] ) ("I love this game; no use"); p.s. The packing iteration interface is very like the yield keyword in C# IEnumeable 3.local/global var declare and using e.g. char a; var_name x, y, z; global_var<int>(y); // put this line inside lambda is ok, just before use it ( ( local_var<int>(x), // local var declare // global_var<int>(y), var(a) = 'a', var<int>(x) = _2, // using local var x ), ( local_var<char>(z), var(a), var<int>(x) = _1, // error! x is not local var here. var<int>(y), // ok for global even if another lambda var<char>(z) = 'b', ) ) p.s. Now, in my work. It's hard to simplify var<T>(x) to var(x). It's a hard template working.

5 14

Re: [boost] [log] Status (was: Is there any interest in a Group of library like to Application System!)
by Andrey Semashev 06 Jan '12

06 Jan '12

On Wednesday, January 04, 2012 09:08:16 Renato Tegon Forti wrote: > Hi Andrey, > > Thanks for your response! What is status of your lib? Do you need any help? The library is moving slowly to v2 release. Right now I'm wrapping up bounded async frontends, I intend to finish them by the weekend. Other things left to be done before the release are: - Port filters and formatters to Phoenix v3. As a part of it, improve error messages in exceptions and make filters and formatters not throw by default. - Introduce "default" sink concept to mitigate problems with trivial and advanced logging coexistence. Trivial logging will no longer initialize the library under the hood. - Implement a common attribute registration mechanism to simplify library extension. This should solve problems with settings file parser not recognizing user-defined attribute types. - Update the documentation. There are many other things to be done but they are not showstoppers for the release. Yes, help would be much appreciated, most notably in the porting to Phoenix v3 part. If anyone is willing to help, please contact me privately or through this list.

3 9

[Graph] Concept check VertexMutablePropertyGraph
by Jens Müller 05 Jan '12

05 Jan '12

Hi, http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/MutablePropertyGraph.ht… (I cannot find docs for VertexMutablePropertyGraph or EdgeMutablePropertyGraph) says that the types boost::graph_traits<G>::vertex_property_type and boost::graph_traits<G>::edge_property_type must exist. However, the concept checks (in boost/graph/graph_concepts.hpp) check for vertex_property_type<G>::type and edge_property_type<G>::type, respectively. Several questions: 1. Should there be separate docs for VertexMutablePropertyGraph and EdgeMutablePropertyGraph? 2. Should there be an actual concept check implementation for MutablePropertyGraph combining the two? 3. Should the concept check look for boost::graph_traits<G>::vertex_property_type instead of ertex_property_type<G>::type? [and the same for edge] 4. For the LEDA adapter, i.e., external adaptation, do I have to specialize vertex_property_type<G> and edge_property_type<G>? Best, Jens

2 3

[graph] VertexListGraph and InputIterator, and LEDA graph
by Jens Müller 05 Jan '12

05 Jan '12

Hi all, I'm currently fixing up leda_graph.hpp so it passes the tests, or indeed, fixing the tests ... A leda::GRAPH<int,int> (=Graph) has to fulfill VertexListGraphConcept. This means that boost::graph_traits<G>::vertex_iterator has to be a MultiPassInputIterator, i.e., also a InputIterator. I cannot read from http://www.sgi.com/tech/stl/InputIterator.html that it must be possible that you can compute the difference between two iterators. But apparently the concept check (which fails) requires a difference type, which must be a signed integer. Is this a bug in the concept check? The vertex_iterator type is defined in leda_graph.hpp using iterator_facade: class vertex_iterator : public iterator_facade<vertex_iterator, leda::node, bidirectional_traversal_tag, const leda::node&, const leda::node*> { public: vertex_iterator(leda::node node = 0, const leda::GRAPH<vtype, etype>* g = 0) : base(node), g(g) {} private: const leda::node& dereference() const { return base; } bool equal(const vertex_iterator& other) const { return base == other.base; } void increment() { base = g->succ_node(base); } void decrement() { base = g->pred_node(base); } leda::node base; const leda::GRAPH<vtype, etype>* g; friend class iterator_core_access; }; Is maybe iterator_facade insufficient? For me, bidirectional_traversal_tag does not indicate that random access is possible ... -- Jens

2 4