Talk:Load-link/store-conditional

message: Citation for CAS-based lock-free reference counting in the face of a changing object-graph, please? --Chris Purcell 11:55, 19 June 2006 (UTC)

message: The article says:
The only limitation of weak LL/SC versus CAS is that the latter is usually guaranteed to be fair, while the former is not. This is also true of strong LL/SC.
Fair in what sense? This needs a citation, especially since the instruction set manuals for Itanium, x86-64, and Sparc don't seem to mention fairness. --JeffreyYasskin (talk) 19:22, 16 December 2007 (UTC)
thread_title:  CAS fairness 

message: The article calls the usual hardware implementations of LL/SC weak. I have, however, the impression, that restricted is more common (e.g. Michael 2004 Hazard pointers: …, Gao and Hesselink 2006 A general lock-free algorithm using CAS, Jayanti and Petrovic 2003 Efficient and practical constractions of LL/SC variables). Further, Jayanti and Petrovic use weak LL/SC in a different sense, where weak LL is allowed to fail, if the subsequent SC will fail (they attribute this use of weak to Anderson and Moir 1995 Universal constructions for large objects). Don’t know whether this hand full of papers is representative… Rathgemz (talk) 12:57, 14 October 2010 (UTC)
thread_title:  Weak LL/SC vs. Restricted LL/SC 

message: Can anyone confirm the relation the new c/c++ standard atomic operations atomic_compare_exchange_weak/strong to ll/sc and especially the difference with CAS? --Itaj Sherman (talk) 02:42, 18 October 2013 (UTC)
thread_title:  relevance to c/c++11 atomics 

message: In particular, it misses that LL/SC works by exploiting interprocessor bus traffic, whereas CAS operates on the basis of atomic access to values alone. Therefore LL/SC isn't vulnerable, and CAS is, to an A-B-A race -- where value A changes to a value B (implicitly, a gamut of other intermediate values), then back to the same value A, with the chain going unnoticed despite being significant to the algorithm. This makes LL/SC impossible to emulate using a CAS primitive alone; further runtime and datatype restrictions would be required (i.e. limiting the object of CAS to garbage-collected pointers only), or high-overhead virtualization of other CPUs' write access to the LL'd memory region through the MMU.
Also, more generally LL/SC is a topic of shared-memory multiprocessing (i.e. inclusive of shared memory clustering as in Mosix) rather than multithreading in particular. In the interest of accuracy, the wording should be revised. For references on the semantic difference, you can quote various CPU architectures' programming manuals. --84.250.160.105 (talk) 04:18, 24 October 2017 (UTC)
thread_title:  Article fails to point out major semantic difference wrt. LL/SC and CAS 

message: The author of rr, the record-and-replay debugger started out of Mozilla, has pointed out that it is impossible to do reliable record-and-replay on architectures with this misfeature. This is what stopped him from supporting ARM. He posted to the RISC-V architecture mailing list pointing out that RISC-V had made the same architectural mistake.
71.46.230.154 (talk) 06:09, 30 May 2019 (UTC)
thread_title:  need to list a disadvantage