Messages in this thread | | | Subject | Re: m68k softirq.h fix | Date | Thu, 24 Dec 1998 10:35:40 +0200 (EET) | From | Matti Aarnio <> |
| |
Alan Cox thus explained: > Graffiti asked: > > I'm still confused. Is there any documentation/book/webpage/gopher hole/etc > > that I can read for this? In particular, what exactly is non-atomic about > > ++/--? > > On some single processor machines the "++" operation is atomic in all > respects. The atomic_t, atomic_inc etc are primarily there for SMP machines > or systems where it may not be. ... > .... So on x86 the atomic_t code generates > lock inc [_variable] > Where lock is an x86 "read-modify-write" instruction - that is one that the > other cpus cannot get at the value while the inc is being done.
Yep, and while CISC machines have these elegant LOCK+INCmem instructions, RISC systems tend to have: MEM->REG loads, REG->REG operations, REG->MEM stores. Specifically, they do *not* have MEM->MEM operations!
In case of Alpha, the code is:
1: ldl_l tempreg,memaddrreg ; Load Long Locked addl tempreg,valuereg,tempreg ; Add to loaded value stl_c tempreg,memaddrreg ; Store Long CondLock ; This is the real jevel at Alpha, hardware ; assists multi-processor coherence by monitoring ; previous "load defined" lock address events ; in the external bus. If a write happens ; at the given address, then 'tempreg' will ; be cleared at the store time. ; (I should pick an Alpha Architecture Manual ; and recheck my memory, "obviously" it should ; set the reg to be non-zero when the store ; succeeds.) beq tempreg,2f ; ... thus allowing this somewhat ; convoluted way to branch back to label 1 ; in case the memory atomicity was violated ; during the store. .section .text2,"ax" 2: br 1b .previous
> Alan
/Matti Aarnio <matti.aarnio@sonera.fi>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |