Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can disable interrupts when modifying locking primitives, and save/restore the CPU context when interrupts are entered/exited. You can also minimize the amount of changes that any interrupt handler can make within the interrupt context.

It's not really that bad, and plenty of microcontrollers lack atomic operations.



If you disable the interrupts, does that mean any incoming events get ignored, or simply queued for later? If the former, that sounds like you risk missing something important.


Queued for later.


Obviously with a certain max depth, most probably of 1, meaning you're still missing repeated interrupts.


Sure, although I think "missing" has negative connotations that don't actually apply to this. When unmasked, your interrupt handler usually just runs until there is no more work to do, which is (again, usually) discoverable. Your device driver is still awoken promptly if the interrupt arrived during a critical section.


The critical section is typically very small, usually just modifying a single variable. Interrupts can't happen faster than the CPU frequency anyway, so you won't miss much.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: