Dan's solution is a perfectly good "word-for-word" translation, but another thing to consider is what the best solution is for ARM (and the typical platform using ARM). If the ARM-based machines are likely to be not super fast, not have many cores, and be very power sensitive (preferring to block rather than spin), it may be better to just rig it so that on ARM, it always uses a true mutex rather than a spin lock.
On Mar 23, 2013, at 5:56 PM, Larry Gritz wrote: > Their first proposed idea was just to change the #ifdef so that for ARM, it > would not attempt to insert any delay at all. That will work, but may not be > optimal (the idea here is to not spin too fast, allow just a bit reduction of > contention on the atomic). > > Dan Wexler's solution is to use 'nop' instead of pause. I don't know enough > about the ARM architecture to know if this is any better, but I can't imagine > that it's worse than doing nothing. I suspect this is the superior solution. > Dan, I don't suppose you'd care to contribute back your ARM fixes? > > In the redhat link, they also mention using usleep, I think that would be a > very bad idea. The idea is to wait a few cycles; usleep will wait a minimum > of microseconds. Surely that will ruin the performance of the spin locks, > making them no faster than an ordinary blocking mutex. > > -- lg > > > On Mar 23, 2013, at 5:45 PM, Daniel Wexler wrote: > >> I used a nop asm instruction to get it to work for me on ARM, though I'm not >> sure if it is any better than their solution. >> >> On Fri, Mar 22, 2013 at 7:28 PM, Richard Shaw <[email protected]> wrote: >> There is an arm specific group within Fedora going through all the >> packages and seeing what will build and what needs fixing. They ran >> into an issue with the "_asm pause" assembler instruction and filed a >> bug[1]. >> >> If you have time could you take a look at their proposed fixes and let >> me know if it's a good idea or if there's a better one. >> >> Thanks, >> Richard >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=924932 >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
