Editing Release consistency (section)

== Implementations ==

=== [[Lock (computer science)|Lock release]] ===
[[File:Lock release in RC.png|thumb|500x500px|A release consistency example implemented by lock release operation.]]
A lock release can be considered as a type of release synchronization. Assume a loop operation is performed using the code shown to the right. Two threads intend to enter a critical section and read the most recent value of {{mono|a}}, then exit the critical section. The code shows that thread 0 first acquires the lock and enters the critical section. In order to execute correctly, P1 must read the latest value of {{mono|a}} written by P0. In that case, only one thread can be in the critical section at a time. Therefore, the synchronization itself has ensured that the successful lock acquisition at P1 occurs after lock release by P0. Besides, the S2 -> S3 ordering has to be ensured, since the P0 must propagate the new value of {{mono|a}} to P1. For the same reason, S5 must occur after S4.<ref name=":0">{{Cite book|title=Fundamentals of Parallel Multicore Architecture|last=Solihin|first=Yan|publisher=Chapman & Hall/CRC Computational Science|year=2015|isbn=9781482211184|pages=315–320}}</ref>

Correctness is not affected if memory accesses following the unlock issue before the unlock complete or memory accesses prior to a lock issue after the lock acquisition. However, the code in critical section can not be issued prior to the lock acquisition is complete because mutual exclusion may not be guaranteed.

=== Post-wait ===
[[File:Post-wait in RC.png|thumb|500x500px|A release consistency example implemented by post-wait synchronization.]]
Post-wait synchronization is another implementation form of release consistency. As shown in the code to the right, correctness can be ensured if post operations occur only after all memory access are complete, especially the store to ‘a’. Apart from that, read operation should not be executed until the wait operation has completed. S2 acts as a release synchronization and S3 acts as an acquire synchronization. Therefore, S2 needs to prevent previous execution from occurring after it, and S3 needs to prevent any later execution from occurring before it. S2 does not need to prevent later  execution from occurring before it, Likewise, S3 does not need to prevent any previous execution from occurring after it.