That only applies for accesses to multiple peripherals (GPIO, SPI, PWM, etc). You shouldn't have any problems if you're only accessing GPIO.hippy wrote: ↑Thu May 23, 2019 10:38 amThe Broadcom BCM 2835 Peripheral PDF talks of read and write memory barriers which should be executed before the first read and after the last write (page 7) -
https://www.raspberrypi.org/app/uploads ... herals.pdf
This is because one isn't actually updating things at the instant a register is written or read but passing commands along a bus to get things updated or read. Don't use the barriers and things can go screwy.
But what if I am accessing GPIO and something else then interrupts and accesses some other peripheral, or another parallel core or GPU accesses a different peripheral, and I don't have a barrier protecting things ?
Code: Select all
My core | Some other core | myStatus = *MY_PERIPHERAL_PTR; | : | itsSatus = *ITS_PERIPHERAL_PTR; return myStatus; | : | return itsStatus;
Code: Select all
My core | Some other core | ReadBarrier(); | : | ReadBarrier(); myStatus = *MY_PERIPHERAL_PTR; | : : | itsSatus = *ITS_PERIPHERAL_PTR; ReadBarrier(); | : : | ReadBarrier(); return myStatus; | : | return itsStatus;
Everything I have now read on DMB and DSB on ARM leads me to believe that, not only does one need to use those, but, in a multi-core environment, one also needs to wrap those and the memory accesses with mutexes or locks.
And yet here we are, 6 years later, every thing seemingly working OK.hippy wrote: ↑Fri May 24, 2019 10:04 amEverything I have now read on DMB and DSB on ARM leads me to believe that, not only does one need to use those, but, in a multi-core environment, one also needs to wrap those and the memory accesses with mutexes or locks.
But, while that will keep one's own code from causing problems, it can do nothing to prevent problems with or caused by other code which isn't using that mutex or lock.
I have said in the past that allowing every program to have unrestricted direct access to GPIO was a bad choice, allowing any program to change GPIO settings which other programs may be relying on, and particularly a problem if that program executes a poorly implemented clean-up routine.
It now seems to me that there are even more fundamental problems with allowing unrestricted access to GPIO, that the whole notion is flawed and seriously problematic for correct operation.
It would be great if someone could point to some documentation on this issue which demonstrably proves that assertion is incorrect. But I haven't found anything which does; everything I have read seems to only suggest it is correct.
"Seemingly" being the operative word; absence of evidence is not evidence of absence.
Which is exactly why I asked PhilE to respond to your question, as he is an expert in this area.. I hope his answer has enlightened you.hippy wrote: ↑Fri May 24, 2019 5:37 pm"Seemingly" being the operative word; absence of evidence is not evidence of absence.
"It has always seemed to worked so far" is hardly proof of there being no bugs or potential problems lurking. I've learned that the hard way, and so have others. There's a whole industry these days around finding bugs and flaws no one has so far spotted.
Open Source would likely not be half as reliable as it is if people weren't questioning what looked dubious to them. Many of the extremely serious bugs identified in recent times have been there for years, in software which otherwise "just worked fine" for millions of people, over billions of execution hours.
Maybe there's a problem, maybe there isn't. I saw a potential issue and asked if anyone could enlighten me. I'll be happy if there isn't an issue, if someone can provide evidence or reassure that it isn't. And I'll be happy if there is an issue and my noticing it ensures it ceases being an issue in the future.
My apologies; I didn't catch the correct context of what you wrote. It sounded a bit like a slightly dismissive "it's been in every nuke we've ever built and none have spontaneously exploded", "people have been smoking our cigarettes for years and no one's complained", but obviously wasn't meant that way.