ReadShared with exclusive access is used to read a location with the intention of updating the location. The same thing can be done using ReadUnique which ensures that the requester gets a unique copy that can then be modified. What is the difference between the two and when would one be used compared to the other?
Exclusive sequences are specifically a read modify write sequence, where the sequence guarantees that no other requesters will store to the location between the read and the write. If another requester does store to the location, then the exclusive sequence fails, the store is not performed and the sequence would need to be restarted. The Store part of the exclusive effectively becomes conditional on no other requesters storing to that location first.
The purpose of exclusives is to allow for synchronisation between different cores or different threads by allowing for a semaphore or lock to be created that enables mutual exclusion for critical sections of code.
Exclusive transactions correspond to LDXR and STXR Arm instructions.
In other words, the purpose of an exclusive ReadShared isn't primarily about trying to update a location. By contrast, a ReadUnique simply always returns data in a Unique state such that it can be written to. The purpose of a ReadUnique is to obtain a cache line so that a store can be performed.
Thanks Christopher for the detailed answer. Your answer seems to imply that using exclusive transactions (RMW) for synchronization is more efficient than getting the ownership of the line and writing back - effectively emulating the RMW. Is this understanding correct?
It's not not exactly about efficiency.
It's more that the Exclusive sequences gives you the ability to create semaphores or locks. In other words, if you wish to perform an Arm Architectural exclusive sequence, then you would use the exclusive sequence flow described in the CHI Specification.
A ReadUnique would be used in cases where no synchronisation is required and the PE simply wishes to write data into a memory location.