--- Quote Start ---
I think that 'disabling the interrupt for a limited time' is quite difficult because we can't detect the instruction despatch and know what pipeline stage deals with the interruptions.
--- Quote End ---
With embedded software we can assume the user processes to be fair, and thus we just should try to avoid a hanging system due to blocked interrupts and so I think a simple timeout of - say - 1000 clock cycles should do here. Of course the user land process would need to re-enable the interrupt as soon as possible.
But I do see another major issue: The interrupt disabling by a custom instruction needs to be done outside of the CPU and thus the timing will be quite sloppy regarding the instructions. So I suppose 100 % atomicness can't be granted and I think the hardware support should be implemented on top of Hippo's suggestion, just in 99,9 % of the cases preventing the necessity for the ISR to bother with the atomic user code, as the ISR is normally not called any more if the user code is in the atomic region.
The mainline macro for an atomic operations would be
___ custom disable interrupt
___ call appropriate_function_in_atomic_page
___ custom enable interrupt
instead of just
___ call appropriate_function_in_atomic_page
if no custom disable interrupt hardware is available
The Kernel code would stay the same.
This problem might make the SMP implementation even more interesting...
-Michael
Honored Contributor
