| Lynn McGuire <lynnmcguire5@gmail.com>: Apr 19 04:13PM -0500 "Functional exception-less error handling with C++23's optional and expected" by Sy Brand https://devblogs.microsoft.com/cppblog/cpp23s-optional-and-expected/ "In software things can go wrong. Sometimes we might expect them to go wrong. Sometimes it's a surprise. In most cases we want to build in some way of handling these misfortunes. Let's call them disappointments." "std::optional was added in C++17 to provide a new standard way of expressing disappointments and more, and it has been extended in C++23 with a new interface inspired by functional programming." Lynn |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 18 07:05PM -0700 Well, it gave me code filled with bugs when I asked it to show me where to place the memory barriers in a mutual exclusion lock: https://i.ibb.co/fYDRNsw/image.png ___________________________ // A mutual exclusion lock. class Mutex { private: // The lock variable. volatile bool lock; public: // Acquires the lock. void Acquire() { // Ensure that the following operations are performed in the correct order. __asm__ volatile("mfence"); lock = true; } // Releases the lock. void Release() { // Ensure that the following operations are performed in the correct order. lock = false; __asm__ volatile("mfence"); } }; ___________________________ It put the membars in the wrong places and did not even think about atomically acquire and releasing the mutex. I feel like correcting it, but why would I do that? Yikes! What a nightmare! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 18 08:18PM -0700 On 4/18/2023 7:05 PM, Chris M. Thomasson wrote: > to place the memory barriers in a mutual exclusion lock: > https://i.ibb.co/fYDRNsw/image.png > ___________________________ [...] > It put the membars in the wrong places and did not even think about > atomically acquire and releasing the mutex. I feel like correcting it, > but why would I do that? Yikes! What a nightmare! It seemed to know what an acquire barrier is on the SPARC. It said: #LoadStore | #LoadLoad This is right but it missed the MEMBAR instruction as in: MEMBAR #LoadStore | #LoadLoad |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 19 06:47PM +0200 Am 19.04.2023 um 04:05 schrieb Chris M. Thomasson: > It put the membars in the wrong places and did not even think about > atomically acquire and releasing the mutex. I feel like correcting it, > but why would I do that? Yikes! What a nightmare! Sorry, that ain't locking. You need to check the before-status and wait for a semaphore if the mutex is already locked. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 19 12:52PM -0700 On 4/19/2023 9:47 AM, Bonita Montero wrote: >> __asm__ volatile("mfence"); >> lock = true; >> } [...] >> but why would I do that? Yikes! What a nightmare! > Sorry, that ain't locking. You need to check the before-status > and wait for a semaphore if the mutex is already locked. Do not know why Bard generate this code, perhaps because it lifted parts of it from of the internet? I was amazed at the errors in here. The Bard needs to be trained. Nobody is paying me to do it. God damn, the errors are abundant. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 19 01:01PM -0700 On 4/19/2023 9:47 AM, Bonita Montero wrote: >> where to place the memory barriers in a mutual exclusion lock: >> https://i.ibb.co/fYDRNsw/image.png >> ___________________________ [snip bugged bard generated code] >> but why would I do that? Yikes! What a nightmare! > Sorry, that ain't locking. You need to check the before-status > and wait for a semaphore if the mutex is already locked. Aside from the atomic locking aspect, it placed the memory barriers in the wrong places. Also, it seems to prefer x86 with its use of the MFENCE instruction. |
| 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