Code: Select all
lock and byte ptr [rcx], 0xf3 //leaving a spinlock
lfence
//do stuff
Out of order loads
Out of order loads
Was looking over a lot of linux code lately, a few locks in particular. I have seen a few of these and was wondering the purpose:
Afaik, lock prefixes act as memory barriers and drain/complete any loads or stores. So I don't see the purpose of the lfence in that case. Can anyone enlighten me, or point me to some reading material? Thanks
Re: Out of order loads
Hi,
However the "lfence" may have been needed as a work-around for bugs in a few CPUs. Specifically, there were bugs in AMD's "family 15" CPUs that involved locks/semaphores and read ordering rules. I think the specific CPU bugs I'm thinking of have been fixed by a micro-code update since, so the "lfence" might just be there in case someone hasn't installed/used the most recent micro-code update, but I really can't be too sure.
Cheers,
Brendan
As far as I know; you're correct and the "lfence" should be unnecessary.devsau wrote:Afaik, lock prefixes act as memory barriers and drain/complete any loads or stores. So I don't see the purpose of the lfence in that case. Can anyone enlighten me, or point me to some reading material? Thanks
However the "lfence" may have been needed as a work-around for bugs in a few CPUs. Specifically, there were bugs in AMD's "family 15" CPUs that involved locks/semaphores and read ordering rules. I think the specific CPU bugs I'm thinking of have been fixed by a micro-code update since, so the "lfence" might just be there in case someone hasn't installed/used the most recent micro-code update, but I really can't be too sure.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Out of order loads
thanks Brendan. I was beginning to think something along those lines.
Re: Out of order loads
Yes, this is AMD errata 147:
http://support.amd.com/TechDocs/25759.pdf
Never was fixed in microcode; Family 15 Rev F2 fixed it in silicon (~2006). And the errata was under NDA for another three years (sigh). It's memorable for how invasive and costly the workaround is. As far as I'm concerned, it's bad enough to render a few years of Opterons as junk - nobody wants to debug lock instructions that don't work right.
Linux kernel mention of the errata: https://bugzilla.kernel.org/show_bug.cgi?id=11305
http://support.amd.com/TechDocs/25759.pdf
Never was fixed in microcode; Family 15 Rev F2 fixed it in silicon (~2006). And the errata was under NDA for another three years (sigh). It's memorable for how invasive and costly the workaround is. As far as I'm concerned, it's bad enough to render a few years of Opterons as junk - nobody wants to debug lock instructions that don't work right.
Linux kernel mention of the errata: https://bugzilla.kernel.org/show_bug.cgi?id=11305