On Mon, 1 Dec 2025 at 14:34, Jon Perryman <[email protected]> wrote:
> On Mon, 1 Dec 2025 11:10:24 -0500, Steve Smith <[email protected]> wrote: > > >I do think that this premature optimization is a bit much for > >initialization code. Making it simple is more important. > > What is it that makes these 256 bytes very time sensitive for the op? > Everyone has ignored that this is for an automation product. Automation > products can be greatly affected by very small time windows. > > This probably isn't about optimization. Instead, it's more likely about > avoiding a deadlock or synchronization situation. More likely than > initialization, this is probably about resetting the counters. > > Solution 1: Instead of zeroing counters, make a copy of the counters and > 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, or why you say (1) and (2) both require binary. . > Solution 2: Use binary numbers instead of packed and XC the 256 bytes. > 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 provide interlocked updates. Notably Add Immediate (ASI and AGSI) and Load and Add (LAA, LAAG). 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. Not my first choice of solutions because a storage overlay can > occur if something takes longer than 30 seconds. > No - just no. Unless you're prepared to use Compare and Swap and friends, and fully understand how to use them. Tony H.
