- std::experimental::atomic_shared_ptr - 5 Updates
- Smelly std::pair and std::tuple - 4 Updates
- Boost circular buffer - 1 Update
| bitrex <bitrex@de.lete.earthlink.net>: May 06 10:57AM -0400 Two questions here: First is, how do I access this template? I'm using GCC 5.4 with C++11, I believe the documentation says I need to include the header <experimental/atomic> but I don't seem to have that anywhere in my installation. Second, if I have one thread which contains a vector of ordinary weak_ptrs, which are dereferenced only to read data from the resource, generated from a vector of shared_ptrs in another thread, which are used to both read from and write to the resource, will making the shared_ptrs in the second thread atomic_shared_ptrs ensure safety from races without modification to the first thread's pointer type? |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: May 06 05:57PM +0200 On 06.05.17 16.57, bitrex wrote: > believe the documentation says I need to include the header > <experimental/atomic> but I don't seem to have that anywhere in my > installation. Probably these experimental files are not part of the usual standard packages. You need to download and install them separately. > to both read from and write to the resource, will making the shared_ptrs > in the second thread atomic_shared_ptrs ensure safety from races without > modification to the first thread's pointer type? You can be pretty sure that the old weak_ptr/shared_ptr and the new atomic pointers are not compatible in any way. It is a distinct type, but you can convert it to shared_ptr. So the usage pattern should always be like atomic_shared_ptr<T> global; // some thread shared_ptr<T> local = global; // work with local The global, strongly thread safe atomic_shared_ptr are not dereferencable at all since they can change at any time making the just received object invalid. BTW: I ended up by writing my own atomic intrusive pointers years ago, additionally providing strong thread safety for global pointers - this will be addressed by atomic_shared_ptr as well. But I still think the concept of intrusive pointers is superior to shared_ptr. Marcel |
| bitrex <bitrex@de.lete.earthlink.net>: May 06 12:48PM -0400 On 05/06/2017 11:57 AM, Marcel Mueller wrote: > will be addressed by atomic_shared_ptr as well. But I still think the > concept of intrusive pointers is superior to shared_ptr. > Marcel Thanks. I'm working on my own graphics/game engine (OpenGL under the hood) and I'm starting to think trying to use these experimental atomic pointers is not really the best approach to my problem. I have an object which holds a vector of weak_ptrs which handles the screen refresh, looping through and calling the underlying display object's "render" method each redraw. But the underlying objects can be deleted at any time from the logic, which is why the visualizer is holding weak_ptrs. I think it's probably just easier to wrap the few places where the display object's fields are written to in a regular lock or mutex. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: May 06 10:09PM +0200 On 06.05.17 18.48, bitrex wrote: > holding weak_ptrs. > I think it's probably just easier to wrap the few places where the > display object's fields are written to in a regular lock or mutex. If you use weak_ptr::lock() there is no need for further synchronization. You might additionally check the unique() function of returned shared_ptr. If it is unique then you are the only one that has a reference which implies that the object is no longer needed and probably needs no screen redraw. You can safely discard it. Marcel |
| bitrex <bitrex@de.lete.earthlink.net>: May 06 06:49PM -0400 On 05/06/2017 04:09 PM, Marcel Mueller wrote: > a reference which implies that the object is no longer needed and > probably needs no screen redraw. You can safely discard it. > Marcel Thank you, good to know! I have been using the lock in the render thread, so it seems it must be something else other than a synchronization issue that's causing my code to segfault... ;-) |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 06 04:16PM +0100 On Sat, 6 May 2017 08:25:33 +1200 > > https://arne-mertz.de/2017/03/smelly-pair-tuple/ > A poorly written article by someone who doesn't appear to understand > where and how tuples are used. Not just tuples, but the author appears unknowledgeable about the proper use of bare data structures generally, which are fine for what they are good at. I am not greatly surprised that Brian agrees with him. |
| David Brown <david.brown@hesbynett.no>: May 06 07:00PM +0200 On 05/05/17 22:25, Ian Collins wrote: >> I agree with him ... https://arne-mertz.de/2017/03/smelly-pair-tuple/ > A poorly written article by someone who doesn't appear to understand > where and how tuples are used. Or at least, where and how tuples /should/ be used. Maybe he has seen them misused a lot. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 06 05:38PM On Sat, 2017-05-06, David Brown wrote: >> where and how tuples are used. > Or at least, where and how tuples /should/ be used. Maybe he has seen > them misused a lot. At this point, I'd appreciate some words about how they should be used. I haven't (as far as I know) had reason to use them myself yet. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Daniel <danielaparker@gmail.com>: May 06 10:38AM -0700 On Friday, May 5, 2017 at 4:25:42 PM UTC-4, Ian Collins wrote: > > I agree with him ... https://arne-mertz.de/2017/03/smelly-pair-tuple/ > A poorly written article by someone who doesn't appear to understand > where and how tuples are used. On the other hand, the author is right about "I'd ... like to have map<K,V>::value_type be something else than a pair<const K, V>". pair<const K, V> pretty much rules out a broad set of containers such as B Trees and B-Plus trees from satisfying the AssociativeContainer concept. Daniel |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 06 04:42PM +0100 On Fri, 5 May 2017 13:34:46 -0400 > clear on whether a resource held by a smart pointer within the > container instead of a regular ol' pointer will be released correctly > if a block in the buffer is overwritten. The text to which you refer is preceded in the documentation by the sentences: "The circular_buffer should not be used for storing pointers to dynamically allocated objects. When a circular buffer becomes full, further insertion will overwrite the stored pointers - resulting in a memory leak." The point being made here is that when the buffer is full, additional pushes to it will overwrite the oldest item, so that if the data items are pointers to items allocated on free store and there is no other pointer held for the item to be overwritten enabling it to be freed, you will have a memory leak. shared_ptr will certainly be safe. As regards how overwriting is dealt with, the documentation says this: 'There was a discussion what exactly "overwriting of an element" means during the formal review. It may be either a destruction of the original element and a consequent inplace construction of a new element or it may be an assignment of a new element into an old one. The circular_buffer implements assignment because it is more effective.' Either approach is OK with shared_ptr. Chris |
| 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