- We've won! - 7 Updates
- Is this sorting predicate ok? - 1 Update
- How to detect wrong Constructor usage... Object A(arguments) vs Object(arguments) - 1 Update
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 25 02:18PM -0800 On 11/25/2018 7:21 AM, David Brown wrote: > Your "Period. End of story." is just like sticking your fingers in > your ears and saying "La, la, la, I'm not listening". It shows that you > are unwilling to think about the situation or read the relevant standards. The standard guarantees that a std::mutex works without having to use any special decorations (atomics, membars, volatile) on the things it protects. Read this response very carefully: https://groups.google.com/forum/#!original/comp.lang.c++/zcVKIRlahZg/qenDx2WYCgAJ I am very happy that all of this is in the standard now. > to /know/ the standards guarantee particular behaviour regarding > ordering and synchronisation - you can't just guess because it looked > okay on a couple of tests, and it would be convenient to you if it worked. Imo, the fact that standard C++11 and C11 guarantee these things now, is great. Assuming a bug free compiler: A std::mutex works fine. However, I never really trusted things before they were integrated into the language and was forced to use externally assembled functions. Check this out, please try to read all, it _is_ an interesting thread: https://groups.google.com/d/topic/comp.programming.threads/KepRbFWBJA4/discussion Fwiw, I was SenderX. ;^) |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 25 02:28PM -0800 On 11/25/2018 8:01 AM, David Brown wrote: > There is /nothing/ in that to suggest that "acquires_count" will not be > accessed if the lock is not acquired. > Use atomic accesses, or volatile accesses, as appropriate. Wrong. The trylock will have acquire semantics when it actually locks, or returns zero in this case. A compiler that does not honor this _fact_ is totally broken wrt the standard. Heck, it is broken even in POSIX. Big time. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 25 10:31PM On 25/11/2018 16:01, David Brown wrote: > Use atomic accesses, or volatile accesses, as appropriate. Why are we still having this argument in 2018? "volatile" is totally useless for multi-threaded synchronization and if you use a std:: mutex then you do NOT need to also use atomics. Atomics are for LOCK-FREE designs. Read the fucking standard Mr Brown. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 26 12:39AM +0200 On 25.11.2018 18:01, David Brown wrote: > (non-atomic, non-volatile) accesses that are inside the locked section > in the source code, are executed entirely within the locked section in > practice. Sorry, it seems like somebody has gone insane here. Mutexes have always worked without needing volatile or atomic and have always protected the accesses inside the locked section - as expected and as designed - in practice. Believe me, if there were a one in a million chance in practice that mutexes would not work this way I would have noticed it by now! If you are right in your claims that the standards do not contain the corresponding verbiage then it would be clearly a defect in the standards. > And it is also wrong to think that just because you sometimes access a > variable within a locked section, that the variable is not accessed when > you don't have a lock. Of course one can write a buggy program where a variable is sometimes accessed under a mutex lock and sometimes not, and unfortunately the C++ language is not powerful or expressive enough to catch this bug. Is this what you are talking about? There are thousands of other ways to write buggy programs in C++. |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 26 12:54AM +0200 On 26.11.2018 0:14, Jorgen Grahn wrote: > Partly because multithreaded software tends to be > subtly broken anyway.) Just curious: do you think it is just so because the multithreaded software tends to be more complex, or do you have any deeper insights about multithreading to back up this claim? |
| David Brown <david.brown@hesbynett.no>: Nov 26 12:13AM +0100 On 25/11/2018 23:28, Chris M. Thomasson wrote: > or returns zero in this case. A compiler that does not honor this _fact_ > is totally broken wrt the standard. Heck, it is broken even in POSIX. > Big time. The C11 standards section covering mutexes in the <threads.h> header (7.26.4) does not mention fences, acquire semantics, or anything else about synchronisation other than between mtx_lock, mtx_trylock and mtx_unlock on the same mutex. The information about acquire and release semantics on mutexes is nothing more than a small note under "5.1.2.4 Multi-threaded executions and data races". But again, let me try to be clear. When mtx_trylock gets the mutex, it has acquire semantics that stops the movement of operations on acquires_count happening before the mtx_trylock() call. If the mtx_trylock call fails, it does /not/ have acquire semantics and has no effect on acquires_count operations. acquires_count is a normal variable - its accesses can be moved around a good deal by the compiler, and the compiler is free to make all sorts of extra reads and writes to it. And again, even if the mtx_trylock call counts as an acquire fence regardless of its success, none of this stops the optimiser changing the code to the equivalent of: int res = mtx_trylock(&mutex); int tmp = acquires_count; tmp += (res == 0); acquires_count = tmp; That optimisation does not in any way break the requirements of mtx_trylock() being an acquire operation. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 25 03:19PM -0800 On 11/25/2018 3:13 PM, David Brown wrote: > acquires_count = tmp; > That optimisation does not in any way break the requirements of > mtx_trylock() being an acquire operation. Yes it does. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 25 10:27PM On Sun, 2018-11-25, Vir Campestris wrote: >> enough to be a competent programmer can easily learn those rules >> in about 15 minutes. > I'm afraid I'm going to disagree with you. ... > And I feel that writing (a & b) ^ c is clearer than leaving the brackets > out. It's obvious what is meant, and I don't have to think about it. Or like I mentioned upthread, what's usually clearer with && and || is to introduce at least one temporary boolean with a well-chosen name. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 26 12:21AM +0200 On 26.11.2018 0:03, peter koch wrote: >> Any advice appreciated. > You can use nodiscard on the class: > class [[nodiscard]] LockingObject [[nodiscard]] only applies if the object is returned from a function, which does not happen here. MSVC2017 and g++ 7.3 agree and compile the following without warnings or errors: class [[nodiscard]] LockingObject { public: LockingObject(int x) {} }; int main() { LockingObject(1); } |
| 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