Page 1 of 1

IO in Preemptive Multitasking

Posted: Sun Feb 24, 2013 8:36 pm
by singerng
How would a preemptive multitasking system use IO routines that are non-interruptable? (for example, HD reading and moving the VGA cursor)? I've found that when these routines get interrupted, chaos seems to ensue, and eventually a fault of some type occurs. How do modern OSes, like Linux and OS X do this?

Re: IO in Preemptive Multitasking

Posted: Mon Feb 25, 2013 12:18 am
by Combuster
HD reading/writing is not non-interruptable and you can pause dealing with the request if so needed. It is however non-reentrant so you can't start a transaction when another hasn't been completed yet. Also, DMA takes care of the atual transfer of data if you're careful actually leaving you time to do other things.

Similar concerns hold for the VGA. The registers in question can be written atomically and if you strictly need that the cursor never appears with the old X and the new Y coordinate, then you should check for things like vertical synchronisation before trying to be sure.

What remains is that the kernel can disable preemption and/or interrupts at its own leasure, so that the truly short I/O sequences and similar critical sections execute without the risk of being split by preemption.

Re: IO in Preemptive Multitasking

Posted: Wed Feb 27, 2013 8:03 am
by turdus
The most frequently used solution is daemons. Restrict the IO access to one process only, and queue requests from other processes. Things will never mix up that way, and you can prevent preemptive task switch while the daemon is in a critical section (only for daemons, other user processes should be preempted).
Typical example is cups, where only one process allowed to access the printer directly, yet many process can print.

Re: IO in Preemptive Multitasking

Posted: Wed Feb 27, 2013 8:54 am
by rdos
Generally, there are two types of solutions for these things:

1. Use semaphores to protect the IO device and let any thread do IO directly
2. Let a server (thread, daemon or process) do all IO, and queue up requests in some way.

I use both alternatives. When the device has IRQs, it is generally best to use a server thread, while in other cases any of the alternatives are possible.