| Christopher Pisz <christopherpisz@gmail.com>: Oct 10 04:25PM -0700 In what scenarios could std::set::erase( const key_type & key) crash a process? I received a crash dump pointing to a block of code where erase is called on a set and the process crashed. I and several of my peers cannot find a thing wrong with the code. I think we are all familiar with the scenario where if you iterate through a container and call erase using the iterator without updating it with the result, that you have invalidated an iterator. However, I am not calling erase with an iterator, but with a key; I've tested calling erase on the same key multiple times and it seems just fine. I've also tested Add and a Remove methods which insert and erase from the set, in 3 threads on random intervals with a set of keys, and cannot get anything bad to happen. I've also checked comparators in the value type used for the set and they are correct, as well as simple. Both operator < and operator == are defined correctly. My set is accessed in multiple threads, but there is indeed a lock_guard at the top of the Add and at the top of the Remove methods. The docs state that erase will not throw. Yet, here I am. Anyone have any ideas on what else one could look for? I am aware that I am not posting code, but my company would greatly frown on that. I completely unable to reproduce the problem in a minimal compilable example. All I have to go on, is that is where the crash dump is pointing every time, on some 50 machines. I've also read over: How can std::set::erase(const key_type& key) cause segfault? std::set<T>::erase(key). What if key isn't there? and those are not the problem. |
| Vir Campestris <vir.campestris@invalid.invalid>: Oct 10 09:51PM +0100 On 09/10/2017 19:33, David Brown wrote: > even though you ideally only want "new" to be called indirectly from > functions like "make_unique". I bumped into an awkward one the other day. There's a static function to get the singleton object, which returns a shared_ptr to it. When I tried to call make_unique I found the author had carefully made the constructor private. I then spent half an hour trying to find what to make a "friend" to allow make_unique to be used. Then gave up. Andy |
| bitrex <bitrex@de.lete.earthlink.net>: Oct 10 01:43PM -0400 On 10/10/2017 10:45 AM, Alain Ketterlin wrote: > optimizes the sequential part correctly). Then play with scheduling > strategies. > -- Alain. Thanks, I'll give OpenMP a look. If I don't have to re-invent the wheel on this one that'd be great. |
| bitrex <bitrex@de.lete.earthlink.net>: Oct 10 01:46PM -0400 On 10/10/2017 10:45 AM, Alain Ketterlin wrote: > optimizes the sequential part correctly). Then play with scheduling > strategies. > -- Alain. The use-case I had in mind was basically application of FIR filtering to data chunks, yes |
| red floyd <dont.bother@its.invalid>: Oct 10 10:06AM -0700 On 10/10/2017 9:48 AM, Scott Lurndal wrote: > For loosely coupled systems, openMPI is the typical answer. *THAT'S* the one I was thinking of. Thanks. |
| David Brown <david.brown@hesbynett.no>: Oct 10 08:28PM +0200 On 10/10/17 19:46, bitrex wrote: >> -- Alain. > The use-case I had in mind was basically application of FIR filtering to > data chunks, yes FIR filtering is a somewhat specialised application. I would guess that your biggest concern is cache - preloading the cache may make more difference than running on multiple threads, and if you end up with contention for data between two threads, it will be slower than a single thread. But if you can split data nicely, then multiple threads can work well here. In any case, you should concentrate first on vectorising SIMD as much as possible, and only look at multiple threads if you need more speed after that. You may even consider using a graphics card for the heavy work. |
| bitrex <bitrex@de.lete.earthlink.net>: Oct 10 09:47AM -0400 On 10/10/2017 08:39 AM, Scott Lurndal wrote: >> the same order after completion. Or use iterators to transform the >> original vector in place from different threads, if that's possible? > Use an autovectorizing compiler and the host SIMD instruction set? I think recent versions of GCC should optimize for SIMD at -O3? In the Code::Blocks build options I also see "CPU Architecture Tuning" flags for AMD FX-64, Intel Core, etc... |
| scott@slp53.sl.home (Scott Lurndal): Oct 10 04:48PM >Intel (cluster OpenMP) which used page faults to synchronize the memory >over the cluster, but for today clustering needs different tools (MPI is >the most standard one) For loosely coupled systems, openMPI is the typical answer. |
| Daniel <danielaparker@gmail.com>: Oct 10 12:04PM -0700 On Tuesday, October 10, 2017 at 1:39:14 PM UTC-4, bitrex wrote: > have some kind of shared global state between instances using either a > singleton or reference counting smart pointer to a common structure > holding the mutable fields, I guess? No, a stateful allocator shouldn't have a default constructor, you should get (want to get!) compile errors if you attempt to construct an object that requires a stateful allocator without providing an allocator instance. Daniel |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment