From a programming point of view, a serialization function delays the CPU on which is it occurring until all previous stores done on that CPU are visible to other CPUs. In practice, on Z machines, it delays the CPU until all prior stores have made it out of the CPU's store buffer and into the cache hierarchy, which is where memory coherency is implemented. So if you have some reason that you don't want your program to proceed until it knows that if another CPU access storage it has stored to, the other CPU will see the values this CPU has stored (and not some prior contents of the storage), you issue an instruction which performs a serialization function.
Architecture allows the processors to be rather lazy about pushing out stores, and by architecture, you would be allowed to see some rather unintuitive results in a multiprocessing environment. Principles of Operation has a lot of words and examples about that. In practice, the engineers tell me that the processors are aggressive about pushing out the stores. Jim Mulder -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Jon Perryman Sent: Sunday, December 7, 2025 11:29 AM To: [email protected] Subject: Re: Effect on the cache when SAM or SAC issued to the current state On Sat, 6 Dec 2025 22:39:51 -0500, Tony Harminc <[email protected]> wrote: >On Sat, 6 Dec 2025 at 15:53, Binyamin Dissen wrote: >> Does the cache get flushed if, for example, SAC 512 is issued when in AR >> mode? > >For SAC, the PofO says "a serialization and checkpoint-synchronization >function *is *performed before the operation begins and again after the >operation is completed" Hardware serialize (cpu) and checkpoint doesn't cause cache to be flushed otherwise 32MB L2 cache wouldn't be useful. Instead, checkpoint commits cache changes to storage. I suspect CPU serialization is required for checkpoint to guarantee multiple cores aren't committing the same cache at the same time. Think of this in terms of the "compare & swap" instruction. Checkpoint is caused by various instructions (PC, SVC, ...), interrupts, checkpoint interval and more. >I don't see that they can fast-path (i.e. skip) these in the >"SAC-to-current" case, because the lack of the >checkpoint-synchronization might in theory be detectable by the program. Cache checkpoint is a hardware feature. Why would a program need to detect it? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
