With multiple CPUs, for costs and design complexity reasons, coordination uses test and set instructions in shared memory.
When the bit is set, other contenders can either try latter or enter a spin loop (spin lock) retrying the operation until it succeeds. Implementing complex hardware atomic instructions coordinated between all CPUs was the norm before RISC chips came out. Simulation proved that this approach was too slow given the speed boost of RISC chips, memory access speed was impaired when implementing complex coordination between all CPUs and RISC chips were spending too much time waiting for the memory subsystem to keep the pace. >From then on, test and set shared memory became the norm. Luc P. > > It's not. Locks are created by using CAS, not the other way around. > > > On a x86 machine the swap basically compiles down to a single assembly > > code instruction: > > > > http://jsimlo.sk/docs/cpu/index.php/cmpxchg.html > > > > On a normal x86 machine, every lock in the system will boil down to > > using this single instruction. x86 has no concept of "locks". Locks > > are simply a construct created by the operating system that is > > implemented with a series of cmpxchg instructions. This is the reason > > this instruction exists in the first place. Every type of > > lock/semephore/mutex we need in a operating system can be built off of > > this single instruction. This is also why Clojure includes atoms. > > > > > > > Ok. Now I understand. So atom wants to take advantage of this hardware high > efficiency CAS. Then I agree if the load is not high, atom will be faster > than locking. Thanks for pointing this out. > > Now I got a broader question, why CAS is hardware supported, but lock is > not (i.e., why it is not the other way around)? I used to work on some > firmware, and we have hardware mutex. Why this is not generally the case > for general purpose CPUs? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
