Previous | Next --- Slide 35 of 44
Back to Lecture Thumbnails
firebb

Just guessing. For Load_linked(x) the processor would issue a BusRdx to exclusively fetch x into its cache. In store_conditional stage, the processor could check if the cache line is still in exclusive state to tell whether x has been modified by other processor. If the cache line is still in exclusive state, the processor could safely store the new value to x.

crow

However, this does not work if another cache reads the address without writing, which would change the cache line from exclusive state to shared state.

Instead of checking if the cache line is in the exclusive state, maybe we could check if it is either in exclusive OR the shared state. Then, if it is in shared, we send a request to move the cache line back into exclusive state before writing.

Firephinx

According to the wikipedia article on LL/SC a lot of the implementations of LL/SC are "weak" in that they would fail if any other operation occurred between the load and the store conditional even if it wasn't related to the variable touched by the operation. This would happen if there was a context switch in between the two operations. The good thing about LL/SC is that it doesn't fall prey to the ABA problem unlike a regular load and compare and swap.

jedi

@firebb in your example, the ABA problem is still possible, whereby the cache line could be swapped into and back out of the X state. Just guessing as well, but it feels safer to set a separate bit after LL, which is cleared whenever the cache line is used by other processors.