![]() | ||||||||||
Messages in this thread |
Followup to: <Pine.LNX.3.95.1020125132236.1362A-100000@chaos.analogic.com> By author: "Richard B. Johnson" <root@chaos.analogic.com> In newsgroup: linux.dev.kernel > On Intel machines, you precede a memory access with the 'lock' > instruction. With CPUs i486, and later, only the accessed page > is locked at that instant. Earlier CPUs locked the whole bus. > > The PCI/Bus controller handles the #LOCK signal itself to guarantee > the atomicity of a transaction. You should never have to do this > yourself. If you think you have to, just precede each PCI/Bus > address-space access with the 'lock' instruction. You just make > your own version of the readl/readw/readb/etc macros that are > provided. You may find that this deadlocks, though, and all bets > are off. You may have just locked the PCI/Bus off the bus when > you needed it most!! > LOCK on readl/readw/etc is meaningless (might even be an error). The *only* case when the lock matters is when transferring read/modify/write transactions such as "inc", "add", "xchg" (the latter locks automatically.) In practice, LOCK# on the PCI bus is so poorly supported that you can't rely on it anyway (and it causes deadlocks.) A number of motherboards have been known not even to wire it up. LOCK is still needed for SMP coherency, however. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 11:15 [W:1.756 / U:0.050 seconds] ©2003-2008 Jasper Spaans | ||||||||||