How the HECK do interrupts work. shouldn't they halve the efficiency of any given program...

how the HECK do interrupts work. shouldn't they halve the efficiency of any given program? since it has to check if the interrupt is active on every cycle. this isn't covered in the k&r book

...

Programs don't check for interrupts.
Your operating system is responsible for managing interrupts.

rly cute picture
what interrupts are you using also you're supposed to use 'blocking IO' or something otherewise you're under arrest

Interrupts aren't checked for every cycle, they're enabled and disabled. If an interrupt is attempted and blocked then it queues up. If you're a big dick then you can write code that permanently disables interrupts letting you lock a processor. This is generally prevented by some extra permissions.

read the book luke
i hope you aren't learning C from k&r, unless you're into bdsm

i don;t use an operating system im programming an avr (。>﹏

>If an interrupt is attempted and blocked then it queues up.
Wrong.

When an interrupt occurs, the interrupt line is just simply held high until it is serviced.
If you ignore the interrupt and another interrupt comes in, then you have missed the last interrupt.
That's why you should only disable interrupts for very short amounts of time, so that you only defer the handling of the interrupt rather than missing any.
Interrupts need to be handled as soon as possible or else they're lost.

In that case interrupts are handled in hardware by your processor.

that's what i don't get, though. if it is executing a command, and monitoring for input, how can it do both on the same cycle? it's only got one core

not him but you can "service" an interrupt by picking it up and just dropping it onto a queue, right?

that way you don't lose anything

This thread will be pruned a couple hours from now when Sup Forums mods finally wake up

But no, that's not how it works

Yes, you can. But interrupts technically aren't disabled, you're just deferring their handling.
Your queue must be able to insert into some kind of list right? inserting into the list must be atomic, or else another interrupt coming in while you're in the middle of inserting could thoroughly fuck things up.
You obviously can't use a mutex/splinlock in an interrupt handler so the only thing you can do is temporarily disable interrupts while inserting to defer any interrupt that may come in during that time.

It checks your pin every cycle.

>fetch
>decode
>execute
>process interrupts

There aren't any additional costs performance-wise because it's implemented in hardware.

I see, that makes sense. I didn't think about the atomicity requirement, which is important because the CPU can call your interrupt handler anytime.

If the interrupt line gets realy congested and some interrupt requests are lost, do those hardware devices just try again after a set interval?

ah ha. so checking that pin for input is part of the processor's architecture? i guess that functionality just isn't used if you have that pin defined as an output?

cute tomato knees !!!

Maki too fat in this picture. Delet- this

I think her sweater is just a bit big user.

Maki

maki!