Differentiating between interrupts for different processes

[srira...@gmail.com]

Hello All,

I am currently reading this book "Computer Organization and Embedded Systems" by Carl Hamacher. I was reading about interrupts. I have not read any books on operating systems yet. I just have a decent understanding of processes. While reading about interrupts, I realised that when a process requests some input data, it will be moved to blocked state and that the processor will send a command to the IO interface requesting for data and also passes information like where it wants the input data to be stored. I also realised that when the data is ready the IO interface will raise an interrupt request. My question is on how the operating system knows which process is the interrupt associated to? If multiple processes are in blocked state waiting for IO how would the OS know which process to wake up. Please help me understand this.

Regards
Raj

PS - My apologies if this is not the right group for this question. I tried comp.os.linus and other comp.os.* groups but most of them are non functional. Please do point me to the right group if any so that I will post my questions there in future.

[nm...@cam.ac.uk]

In article <4519530.2.1335460771651.JavaMail.geo-discussion-forums@pbbpg8>,
<srira...@gmail.com> wrote:
>
>I am currently reading this book "Computer Organization and Embedded System=
>s" by Carl Hamacher. I was reading about interrupts. I have not read any bo=
>oks on operating systems yet. I just have a decent understanding of process=
>es. While reading about interrupts, I realised that when a process requests=
> some input data, it will be moved to blocked state and that the processor =
>will send a command to the IO interface requesting for data and also passes=
> information like where it wants the input data to be stored. I also realis=
>ed that when the data is ready the IO interface will raise an interrupt req=
>uest. My question is on how the operating system knows which process is the=
> interrupt associated to? If multiple processes are in blocked state waitin=
>g for IO how would the OS know which process to wake up. Please help me und=
>erstand this.

You have just asked a question to which the complete answer is very
complicated, and you would almost certainly not understand it. The
naive answer is that the I/O interface knows which process has
requested data from which I/O 'device', and it is the I/O interface
that the interrupt is associated with.

But several regulars here will know that I know better that to say
that is always the case :-)

>PS - My apologies if this is not the right group for this question. I trie=
>d comp.os.linus and other comp.os.* groups but most of them are non functio=
>nal. Please do point me to the right group if any so that I will post my qu=
>estions there in future.

It's definitely not. Unfortunately, I am not sure that there is a
right group any longer. Sorry.


Regards,
Nick Maclaren.

[Joe Pfeiffer]

srira...@gmail.com writes:

> Hello All,
>
> I am currently reading this book "Computer Organization and Embedded
> Systems" by Carl Hamacher. I was reading about interrupts. I have not
> read any books on operating systems yet. I just have a decent
> understanding of processes. While reading about interrupts, I realised
> that when a process requests some input data, it will be moved to
> blocked state and that the processor will send a command to the IO
> interface requesting for data and also passes information like where
> it wants the input data to be stored. I also realised that when the
> data is ready the IO interface will raise an interrupt request. My
> question is on how the operating system knows which process is the
> interrupt associated to? If multiple processes are in blocked state
> waiting for IO how would the OS know which process to wake up. Please
> help me understand this.

Every pending IO request has all the information it needs to be
satisfied, stored with it in a data structure in the operating system.
So, if a process has to be blocked pending IO, "which process" is one of
the things stored in this data structure.

[EricP]

The details would be different for each OS,
but in general one approach is:
- the IO system service routine copies the all the info necessary
into an IO packet, including a pointer back to the process.
- The packet is passed to the driver and the IO is started.
- The process puts itself to sleep by removing itself from the
Ready queue (the list of processes eligible to run).
- The interrupts arrives indicating the device has finished.
- The driver cleans up after the IO and wakes the process up by
following the pointer in the Io packet back to the process,
moving it back to the Ready queue, and kicking the scheduler.

There is plenty of OS internals info available.

- Lots of universities have some or all of their course material online.
Use Google and restrict your search to .edu sites.
For example the search

io "operating systems" site:.edu

gets lots of hits.

- There is a news group alt.os.development where hobbyist
OS developers (people building their own OS) hang out.

Websites on OS internals or development:
http://tldp.org/LDP/tlk/tlk.html The Linux Kernel
http://williamstallings.com/OS4e.html
http://tunes.org/Review/OSes.html
http://wiki.osdev.org/Main_Page

Books (possibly available online):
Operating Systems Concepts by
by SILBERSCHATZ, GALVIN, GAGNE

Microsoft Windows Internals
by Russinovich, Solomon

Linux Kernel 2.4 Internals
by Tigran Aivazian

A detailed understanding would require a good knowledge of programming.

Eric

[EricP]

EricP wrote:
> srira...@gmail.com wrote:
>> Hello All,

>>
>
> - Lots of universities have some or all of their course material online.

Lots of UofBerkeley Computer Science lecture videos (about 1.5 hours each).

http://webcast.berkeley.edu/series.html#c,d,Computer_Science

This set is on Operating Systems.
Lecture 12 covers IO, amongst other things.

http://webcast.berkeley.edu/playlist#c,d,Computer_Science,EAFEC6160DADC7AA

Eric

[Bakul Shah]

On 4/26/12 10:19 AM, srira...@gmail.com wrote:
> Hello All,
>
> I am currently reading this book "Computer Organization and
> Embedded Systems" by Carl Hamacher. I was reading about
> interrupts. I have not read any books on operating systems
> yet. I just have a decent understanding of processes. While
> reading about interrupts, I realised that when a process
> requests some input data, it will be moved to blocked state
> and that the processor will send a command to the IO interface
> requesting for data and also passes information like where it
> wants the input data to be stored. I also realised that when
> the data is ready the IO interface will raise an interrupt
> request. My question is on how the operating system knows
> which process is the interrupt associated to? If multiple
> processes are in blocked state waiting for IO how would the OS
> know which process to wake up. Please help me understand this.

The processor h/w will transfer control to an "interrupt
handler" whose address is associated with the specific
interrupt source. How this address is associated is processor
specific and may require software assist. Also note that the
previous context has to be saved; this is typically done by
the processor itself but may require software assist.

This interrupt handler routine knows what to do, based on what
it knows about the device it is responsible for, and by
accessing some global state, such as the list of processes
that may be waiting for the request being serviced.

This is just a simplistic sketch to point you in the right
direction. There is a lot of variety in how all this gets done
on various processors.

> PS - My apologies if this is not the right group for this
> question. I tried comp.os.linus and other comp.os.* groups but
> most of them are non functional. Please do point me to the
> right group if any so that I will post my questions there in
> future.

In addition to reading OS books, try sites such as
stackoverflow.com. Unfortunately Usenet is on life support.

[Quadibloc]

On Apr 26, 11:19 am, srirajvi...@gmail.com wrote:
>I also realised that when the data is ready the IO interface will raise an >interrupt request. My question is on how the operating system knows >which process is the interrupt associated to? If multiple processes are >in blocked state waiting for IO how would the OS know which process >to wake up.

The answer to this is very simple, because you are suffering from a
misconception.

Let us imagine a computer with an operating system.

A user's program wants to read a file. So it asks the operating system
for data from the file. And the subroutine for getting the data will
not return until the data is ready.

Eventually, the disk drive sends an interrupt to the computer to say
it is ready.

That interrupt begins a new process in supervisor state which reads
the data from the disk into a buffer.

In between that, what happened was:

The disk read routine started the disk on the way to reading the
appropriate sector - and it left a note for the interrupt routine
telling it which user task the data it would read would be for.

So the interrupt mechanism doesn't sort out which user process an
interrupt is ultimately going to benefit. The kind of interrupt leads
to an appropriate vector for handling such interrupts - and the
connection between hardware events and the programs which ultimately
receive their results is handled outside the interrupt mechanism by
the operating system.

John Savard

[nm...@cam.ac.uk]

In article <c26a6289-d5ba-4685...@w6g2000pbp.googlegroups.com>,

Quadibloc <jsa...@ecn.ab.ca> wrote:
>On Apr 26, 11:19 am, srirajvi...@gmail.com wrote:
>>

>>I also realised that when the data is ready the IO interface will raise an=
> >interrupt request. My question is on how the operating system knows >whic=
>h process is the interrupt associated to? If multiple processes are >in blo=

>cked state waiting for IO how would the OS know which process >to wake up.
>
>The answer to this is very simple, because you are suffering from a
>misconception.

Quite. While what he is assuming happens, it is not the norm.

>So the interrupt mechanism doesn't sort out which user process an
>interrupt is ultimately going to benefit. The kind of interrupt leads
>to an appropriate vector for handling such interrupts - and the
>connection between hardware events and the programs which ultimately
>receive their results is handled outside the interrupt mechanism by
>the operating system.

I will raise you the sort of RDMA used in HPC and/or the System/360 :-)
To the OP: ignore that, as it will merely confuse you.


Regards,
Nick Maclaren.

[ChrisQ]

The first thing to note is that interrupts are primarily a hardware
function,
whereas processes, io requests etc, are a software functions and at a
higher
level, if you think of the overall system as a set of layers.

For most of the early micros, several hardware devices shared, (wired OR,
open collector) a single processor interrupt pin, or input line. Under
such conditions, the only way to determine the source of interrupt is to
sequentially poll all the hardware device status registers within the first
few lines of the interrupt handler to see which has the interrupt bit set,
then branch to the appropriate code to process that interrupt. This is
not very
efficient, especially if real time constraints must be met, so most
respectable
modern micros use the vector table approach. Here, each interrupting
device has
a unique address in memory which contains the address of the interrupt
handler.
The vector table is set up at processor startup, before interrupts are
enabled.
When an interrupt occurs, the vector address corresponding to the device
is read
and the contents loaded into the program counter, resulting in immediate
transfer
of control to the interrupt code. This is much faster, since no s/w polling
is required and the work is done at hardware level.

In practice, there's more to it than this, but if you need more info,
find a copy
of the 6800, 6502 processor reference manual for the polled model, or
pdp11 or 68000
processor reference manuals for the vector table approach. I pick these
because they
are fairly simple designs in terms of understanding. If you want a more
modern design,
he Cortex M3 uses the vector table approach and pretty much state of the
art...

Regards.,

Chris