On Mon, 1 Dec 2025 19:37:28 -0500, Tony Harminc <[email protected]> wrote:
>> Solution 2: Use binary numbers instead of packed and XC the 256 bytes. > >Not obvious to me why this approach requires binary counters, If a product can require z unsigned-packed-decimal support, then XC could be preferred otherwise a sign of 0 will cause an exception. >> Solution 1: subtract the previous counters from the copy to give the delta. >> This >> solution requires the counters be binary. > >Not obvious to me why this approach requires binary counters, Binary numbers wrap positive, neg, pos, neg, ... Packed numbers require extra calculations to determine difference. Certainly doable. >> You'll still need a copy of the counters for your calcs and counters can be >> incorrect because you can't serialize. > >Not so. On any modern machine (post 2010 or so), which will have >the Interlocked-Access Facility 1 installed, a handful of instructions Interlock doesn't help for situations where multiple counters must be considered a unit of work when being processed prior to being zeroed. I believe that unsigned-packed-decimal was implemented around that same time. If a product can make that a requirement, then XC would be the better solution. >Solution 3: Replace the pointer to the counters with a pointer to the new >> counters. Wait 30 seconds before using the old counters in case something >> is inflight. > >No - just no. Unless you're prepared to use Compare and Swap and friends, >and fully understand how to use them. Compare & swap is not a locking mechanism (e.g. GRS) which solves completely different types of problems. The 30 second wait is in lieu of every event needing an enqueue which compare and swap cannot solve. For instance, we expect an address space to be swapped in within 30 seconds that may have loaded the pointer but not updated the counter.
