Timeline for C++ minimal threadsafe array based on std::deque
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 1, 2017 at 17:15 | comment | added | Quuxplusone |
(iii) My only point re memory-orders is that you'll probably get them wrong even if you think hard about them — and certainly if you go by "intuition"! Prefer the safety of seq_cst, especially on x86 where the different memory-orders give identical codegen anyway. Ask yourself: is it worth the extra keystrokes, if all you're doing is introducing bugs for ARM users? :)
|
|
| Aug 1, 2017 at 17:12 | comment | added | Quuxplusone |
(i) Nothing wrong with a deque as long as you take the mutex lock at the right times. I think you'll find the same problems cropping up with raw T**, although I admit I'm not sure exactly what you're thinking of. (ii) threadsafe_array's copy and move ops are implicitly deleted because threadsafe_array has non-moveable members (the atomic and the mutex).
|
|
| Aug 1, 2017 at 14:31 | comment | added | davidhigh |
(iii) With respect to the memory order: as far I know std::memory_order_seq_cst does not prevent the reordering of non-atomic accesses to after the respective position, and I wanted the previous push_back happen first ... this is why I chose std::memory_order_release. The std::memory_order_acquire then came in rather intuitively (this is why I asked whether it's correct). The main question was, whether the update strategy is resp. can be made correct, i.e. lock only the write accesses (which are always push_backs) and don't lock the read accesses unlocked. What do you mean?
|
|
| Aug 1, 2017 at 14:26 | comment | added | davidhigh |
Seems then that I'm a five, and there's lots to learn ahead, so thanks for your comments. (i) the deque-access error is there from the principles, and it's also good to see it in action. Probably a stable, non-contigouos T** is more appropriate here. (ii) I didn't want to focus on the copy-constructor, so I'd have it better deleted, but as it is it's implicitly there and thus surely a bug, so thanks for pointing.
|
|
| Aug 1, 2017 at 0:05 | history | answered | Quuxplusone | CC BY-SA 3.0 |