Andrew Johnson commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5214#note_119953 Isn't the fundamental issue here that an interrupt should never corrupt the FPSR of a thread that gets interrupted? A piece of code running in one thread (Task A) should be able to perform an operation that results in some FPSR bits being set, and then read those bits to act on them. If an interrupt occurs in between the two and results in a different thread (Task B) being preemptively scheduled, the interrupt/scheduler code needs to save the FPSR value from the first thread, so that the second one can perform its own FP operations that could change the FPSR, then the scheduler must restore the FPSR before it returns to the first thread again. I suspect @opticron is seeing the delay calls in the above description as permitting the FPSR to be corrupted in the example, but @pfaiks is concentrating on the problem that FP operations in another thread is what is actually changing the FPSR value in the example. The delays were presumably included to maximize the chances that an interrupt will occur between the FPSR being set and then read, but it should be possible to replace those calls with a busy-wait loop to remove that aspect. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5214#note_119953 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
