An interrupt is nothing more and nothing less than .. "a little bell that goes off now and then" for various reasons. The computer can: respond to it, put it off for a bit, or stuff its head back underneath the pillow and ignore the thing completely.

Interrupts are simply nature's way of keeping a computer from spending 100% of its time fruitlessly waiting for something to happen. When something does happen, the little bell will ring. That's it. That's all.

I/O operations actually can happen in a different order from whence they were requested. The TCP/IP packets of a conversation can be sent in any order; the software protocol has to know how to renumber them and to detect that any of them are missing. Disk I/O requests are sorted in such a way that the read/write head assembly moves as efficiently across the platter as it possibly can ("seek time" being by-far the longest component of access time). (Sometimes a disk-write request doesn't actually cause a write to take place at all! So-called "lazy writing.")

I hope that my various attempts at explanation were helpful.

Hi. Onebuck, are you suggesting the kernel doesn't know the order of data it is receiving, or that it has some other way of knowing the order than the responses comming in order, or the order being tagged somehow?

If the patent is wrong, how does the kernel know the order the data is supposed to be in?

sundialsvs TCP packets use a SEQ (sequence number) to know order. Now that I have read this post, I am curious how the kernel knows the order of data, without it either being tagged, or received in order.

needle_

Let's try to discern this mystery. The order has to somehow be specified. Whether it be unknown-quantum-voodoo-science (I think microsoft uses that form of ordering) or whether it be clearly stated as either a rule to default on or information communicated, that needs interpreted and/or parsed.

I think the topic has been covered, unless anyone can give an example out of interest, of a device that responds to requests out of order, and has any information outlining the protocol that communicates the order. (I don't think even a network card does that, it simply can receive the information out of order because of the difference in routes and the path that the packet takes traversing the internet, I still imagine it sends information inside the computer, in the order in which the network card received it, not that it entirely matters, the information is tagged to know which queue it belongs, and in which order.).

needle_

Hi,

Welcome to LQ!
No, I made no suggestion. The Kernel does use the scheduler to control priorities. Hardware PIC controls the basic interrupt process which is serviced by a Interrupt handler routine. Once the kernel is aware of the service request then the kernel scheduler will handle the time slice for the service routine of the device. Data flow control will be dictated by the device driver and device. Protocol is set for the device type. One must remember that higher priority service requests may interrupt a current process, this is handled via the PC(program counter) and stack which is used to store return information that will bring things back to the state before the interrupt. Kernel scheduler will determine the time slice and priority for the service.

You can look at 'Linux Kernel Interactive Map' to get a good overview. Plus you can look at Interrupt Handling
& Linux Scheduling and Kernel Synchronization which are detailed explanations.

HTH!