- Boost - lists.preview.boost.org

[interprocess] leaked named mutexes
by Eric Niebler 07 Mar '13

07 Mar '13

I recently discovered that a process can very easily leave a named mutex dangling. Consider the following: #include <cstdlib> #include <iostream> #include <boost/interprocess/sync/named_mutex.hpp> #include <boost/interprocess/sync/scoped_lock.hpp> namespace ip = boost::interprocess; char const *name = "mynamedmutex"; int main(int argc, char*argv[]) { ip::named_mutex mtx(ip::open_or_create, name); std::cout << "acquiring named mutex" << std::endl; ip::scoped_lock<ip::named_mutex> lock(mtx); std::cout << "acquired" << std::endl; exit(EXIT_FAILURE); // whoops } On my Linux box, this runs fine the first time, but the second time it hangs waiting to acquire the mutex. I have to manually delete the semaphore in /dev/shm/. This will happen whenever the process exits without calling destructors of locals; for instance: - std::exit - std::quick_exit - std::abort - std::terminate - a crash - assert failure - an unhandled exception - etc.. I find I can handle *some* of this by registering a terminate handler, an exit handler (and on C++11, a quick_exit handler) that calls boost::interprocess::named_mutex::remove. This raises a few questions, though... - Is there a better way? - Is it safe to `remove` the same named mutex multiple times? - Does this clean up only this process's use of the named_mutex, or does it nuke it from the system, even if another process is using it? (The docs suggest the latter, which is not what I want, is it?) Thanks, -- Eric Niebler Boost.org

5 5

[Graph][Parallel][PBGL] Bug deleting self loop edges
by bminano 07 Mar '13

07 Mar '13

Hello, I think I found a bug in the graph parallel library. I have a bidirectional adjacency list which has some self loop edges. When I try to delete them with remove_edge_if (or remove_out_edge_if or remove_in_edge_if) the edges are deleted, but it seems that some reference gets broken in the graph. If I iterate over the in_edges a reference to a self loop is found. But it does not happen if I iterate over the out_edges. If the graph is written in a graphviz file the self loop edges does not appear. I think there is some broken reference into the adjacency list that keeps the in_edges. I have two different pieces of code (one with pbgl and the other with bgl). They do the same, create a graph, delete the self-edges and print the in_edges. Could someone have a look at this problem? We want to use this library in our research but with this problem will not be possible. Thank you pbgl_in_edges.cpp <http://boost.2283326.n4.nabble.com/file/n4643903/pbgl_in_edges.cpp> bgl_in_edges.cpp <http://boost.2283326.n4.nabble.com/file/n4643903/bgl_in_edges.cpp> -- View this message in context: http://boost.2283326.n4.nabble.com/Graph-Parallel-PBGL-Bug-deleting-self-lo… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] [math] Support for libquadmath/ __float128
by John Maddock 07 Mar '13

07 Mar '13

>> Including that header will only work (as in not generate a compiler >> error) >> if the compiler supports __float128 as a native type, which is what we >> want >> to work out... basically whether the GCC build was configured to support >> it >> or not. > > The current libstdc++ headers define _GLIBCXX_USE_FLOAT128 if > __float128 is supported, but that's an implementation detail and > shouldn't be relied on (relying on _GLIBCXX_HAS_GTHREADS broke > Boost.Threads recently when GCC 4.7 stopped defining it.) I've added minimal __float128 support in Boost.Math Trunk: it's enabled whenever BOOST_MATH_USE_FLOAT128 is set, which it is automatically when the above macro is detected (which I note libstdc++ doesn't seem to use anywhere itself). Also filed a gcc bug report on the lack of a __SIZEOF__ macro for __float128: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540 HTH, John.

2 1

make_shared causes stack overflow with large objects
by Gregor Jasny 07 Mar '13

07 Mar '13

Hello, the bug described in #7965 causes stack overflows and sometimes hard to track crashes. I'd really appreciate if anyone could have a look. Thanks, Gregor

2 3

Re: [boost] [compute] GPGPU Library - Request For Feedback
by Hartmut Kaiser 07 Mar '13

07 Mar '13

> On Sun, Mar 3, 2013 at 6:39 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> > wrote: > > > > Also, do you have asynchronous versions for all algorithms? > > As of now only copy_async() is implemented (as it is the most important > for achieving good performance by overlapping memory transfers with > computation). However, I am not sure if this is the best interface to be > extended to all the other algorithms. > > I've been thinking about moving towards an asynchronous execution function > like std::async() which would be passed the algorithm function along with > its arguments. However, I've encountered problems with overloading and > having to explicitly specify the argument template types. This is one > point where I'd like to get some feedback/ideas from the community. I > would also like to have a > <algorithm>_async_after() version which would take the algorithms > parameters along with a list of futures/events to wait for before > beginning execution. My dilemma is that extending these different versions > would increase the size of the API by a factor of three. > > Any feedback/ideas/comments would be very helpful. I'd strongly suggest not to add <foo>_async_after(). All we need is a) a function/algorithm producing a future b) composable futures (see N3428, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3428.pdf) But for this to be universally applicable we should try to find a way to converge onto ONE future type. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 1

Re: [boost] [compute] GPGPU Library - Request For Feedback
by Jeffrey Lee Hellrung, Jr. 06 Mar '13

06 Mar '13

On Mon, Mar 4, 2013 at 6:25 PM, Kyle Lutz <kyle.r.lutz(a)gmail.com> wrote: > On Sun, Mar 3, 2013 at 6:39 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> > wrote: > > > > Also, do you have asynchronous versions for all algorithms? > > As of now only copy_async() is implemented (as it is the most > important for achieving good performance by overlapping memory > transfers with computation). However, I am not sure if this is the > best interface to be extended to all the other algorithms. > > I've been thinking about moving towards an asynchronous execution > function like std::async() which would be passed the algorithm > function along with its arguments. However, I've encountered problems > with overloading and having to explicitly specify the argument > template types. This is one point where I'd like to get some > feedback/ideas from the community. I would also like to have a > <algorithm>_async_after() version which would take the algorithms > parameters along with a list of futures/events to wait for before > beginning execution. My dilemma is that extending these different > versions would increase the size of the API by a factor of three. > > Any feedback/ideas/comments would be very helpful. > This sounds vaguely similar to Google's Flume framework: http://dl.acm.org/citation.cfm?id=1806638 - Jeff

1 0

Re: [boost] [compute] GPGPU Library - Request For Feedback
by Hartmut Kaiser 06 Mar '13

06 Mar '13

> > That's excellent (sorry I have not seen this in the docs before). > > However I think it's not a good idea to create your own futures. This > > does not scale well nor does it compose with std::future or > > boost::future. Is there a way to use whatever futures (or more > > specifically, threading implementation) the user decides to use? > > The boost::compute::future class wraps a cl_event object which is used to > monitor the progress of a compute kernel. I'm not sure how to achieve this > with std::future or boost.thread's future (or even which to chose for the > API). Any pointers (or example code) would be greatly appreciated. Yes, that's exactly the problem. It is nothing specific to your particular library but a general issue to solve. In the library we develop (HPX, https://github.com/STEllAR-GROUP/hpx/) we face the same issue of having to rely on our own synchronization primitives which makes it impossible to reuse std::future (or boost::future). Any suggestion on how to create specialization/customization points allowing to make boost::future universally applicable would be most appreciated. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Re: [boost] [compute] GPGPU Library - Request For Feedback
by Ioannis Papadopoulos 06 Mar '13

06 Mar '13

On 3/4/2013 8:47 PM, Kyle Lutz wrote: > On Sun, Mar 3, 2013 at 9:15 PM, Ioannis Papadopoulos > <ipapadop(a)cse.tamu.edu> wrote: >> A comparison would be nice. Moreover, why not piggy-back on the libraries >> that are already available (and they probably have better optimizations in >> place) and simply write a nice wrapper around them (and maybe, crazy idea, >> allow a single codebase to use both AMD and nVidia GPUs at the same time)? > > Boost.Compute does allow you to use both AMD and nVidia GPUs at the > same time with the same codebase. In fact you can also throw in your > multi-core CPU, Xeon Phi accelerator card and even a Playstation 3. > Not such a crazy idea after all ;-). > > -kyle > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > Thanks for the comparison. The only issue I see with Boost.Compute is that it will have problems supporting well the well-known architectures. Basically, it takes all the optimizations that have been researched and developed for maximum efficiency and throws them out of the window. For example, there is a wealth of CUDA algorithms highly optimized for nVidia GPUs. These will have to be reimplemented in OpenCL. And tuned (ouch); possibly for each device (ouch x 2). I see it as a massive task for a single person or a small group of people that are doing that in their spare time. However, if Boost.Compute implements something similar to Boost.Multiprecision's multi-backend approach, then you can use underneath thrust, Bolt, whatever else there is and only fall-back to the OpenCL code if there is nothing else (or the user explicitly requires it). They way I'd see something with the title Boost.Compute is as an algorithm selection library - you have multiple backends, which you may choose from based on automatic configuration at compile time and at run time based on type and input size of your input data. Starting from multiple backends is a good start.

1 0

Re: [boost] License of endian and limits in Boost detail
by Philip Bennefall 06 Mar '13

06 Mar '13

----- Original Message ----- From: "Rob Stewart" <robertstewart(a)comcast.net> To: <boost(a)lists.boost.org> Sent: Wednesday, March 06, 2013 12:12 AM Subject: Re: [boost] License of endian and limits in Boost detail On Mar 5, 2013, at 2:29 AM, Philip Bennefall <philip(a)blastbay.com> wrote: > * Permission to use, copy, modify, distribute and sell this software > * and its documentation for any purpose is hereby granted without fee, > * provided that the above copyright notice appear in all copies and > * that both that copyright notice and this permission notice appear > * in supporting documentation. > > This looks to me like it enforces inclusion of the above text in object > code distributions, IANAL, but I read that as only requiring the copyright notice in copies of the source and in the documentation, not in the binaries. Do you mean the end user documentation accompanying binaries (e.g. the documentation of a derivative work)? That is the part I want to avoid. Philip Bennefall ___ Rob _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

7 8

ESA Summer of Code in Space
by Thomas Heller 11 Jul '11

11 Jul '11

Hi List, I just read about the ESA Summer of Code in Space (SOCIS) program. Looks similar interesting that GSOC. I just wanted to probe interest in that program. I would volunteer on taking further actions, the mentoring organizations application deadline is on 07/15 so its on rather short notice. Andrew, you took care of the GSOC application, right? Best regards, Thomas

1 0