Types of Software Systems : Diagnostic Software Systems, Sensor and Signal Processing Systems, Simulation Systems

The type of software system refers to the processing that will be performed by that system.
Diagnostic Software Systems:
These systems helps in diagnosing the computer hardware components. When a new device is plugged into your computer, a diagnostic software system does some work. The "New Hardware Found" dialog can be seen as a result of this system.

Sensor and Signal Processing Systems:
The message processing system helps in sending and receiving messages. These systems are more complex because they make use of mathematics for signal processing. In a signal processing system, the computer receives input in the form of signals and then transforms the signals to a user understandable output.

Simulation Systems:
Simulation is the process of designing a model of a real system and conducting experiments with this model for the purpose of understanding the behavior of the system or evaluating various strategies for the operation of the system. A simulation is a software package that re-creates or simulates, albeit in a simplified manner, a complex phenomenon, environment, experience providing the user an opportunity for some new level of understanding.
Simulation systems are easier, cheaper and safer to use as compared to real systems and often the only way to build the real systems. For example, learning to fly a fighter plane using a simulator is much safer and less expensive than learning on a real fighter plane. System simulation mimics the operation of a real system such as the operation in a bank or the running of an assembly line in a factory.
Simulation in the early stage of design cycle is important because the cost of mistakes increases dramatically later in the product life cycle. Also, simulation software can analyze the operation of a real system without the improvement of an expert i.e. it can also be analyzed with a non-expert like a manager.

Introduction to Monitors

Monitors :
- Consist of private data and operations on that data.
- It can contain types, constants, variables and procedures.
- Only the procedures explicitly marked can be seen outside the monitor.
- The monitor body allows the private data to be initialized.
- The compiler enforces mutual exclusion on a particular monitor.
- Each monitor has a boundary queue, and processes wanting to call a monitor routine
join this queue if the monitor is already in use.
- Monitors are an improvement over conditional critical regions because all the code
that accesses the shared data is localized.

To allow a process to wait within the monitor, a condition variable must be declared, as: condition x,y.
Condition variable can only be used with the operations wait and signal.
The operation x.wait()means that the process invoking this operation is suspended until another process invokes. Also called delay function.
The operation x.signal()resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect.Also called resume function.

Monitor Implementation using Semaphores
- For each condition variable x, we have:
semaphore x-sem; // (initially = 0)
int x-count = 0;
- The operation x.wait can be implemented as:
x-count++;
if (next-count > 0)
signal(next);
else
signal(mutex);
wait(x-sem);
x-count--;
- The operation x.signal can be implemented as:
if (x-count > 0)
{
next-count++;
signal(x-sem);
wait(next);
next-count--;
}

Edge Triggered Interrupts

An edge-triggered interrupt is a class of interrupts that are signalled by a level transition on the interrupt line, either a falling edge (1 to 0) or a rising edge (0 to 1). A device wishing to signal an interrupt drives a pulse onto the line and then releases the line to its quiescent state. If the pulse is too short to be detected by polled I/O then special hardware may be required to detect the edge. This type of interrupt is useful for a fleeting signal that doesn't last long enough for the processor to recognize it using polled I/O or for when the signal can last a long time, but the significant event is when that signal first goes active.
Edge-triggered interrupt modules can be acknowledged immediately, no matter how the interrupt source behaves. The type of the interrupt source does not matter. It can be a pulse, a firmware-clear signal, or some external signal that eventually is cleared somehow. Edge-triggered interrupts keep firmware’s code complexity down, reduce the number of conditions firmware needs to be aware of, and provide more flexibility when interrupts are acknowledged. This keeps development time down and quality up.
Multiple devices may share an edge-triggered interrupt line if they are designed to. The interrupt line must have a pull-down or pull-up resistor so that when not actively driven it settles to one particular state.Devices signal an interrupt by briefly driving the line to its non-default state, and let the line float (do not actively drive it) when not signaling an interrupt. This type of connection is also referred to as open collector. The line then carries all the pulses generated by all the devices.
Edge-triggered interrupts do not suffer the problems that level-triggered interrupts have with sharing. Service of a low-priority device can be postponed arbitrarily, and interrupts will continue to be received from the high-priority devices that are being serviced. If there is a device that the CPU does not know how to service, it may cause a spurious interrupt, or even periodic spurious interrupts, but it does not interfere with the interrupt signaling of the other devices.

Level Triggered Interrupts

Level-triggered Interrupt : It is the class of interrupts where the presence of an unserviced interrupt is indicated by a high level (1), or low level (0), of the interrupt request line. A device wishing to signal an interrupt drives the line to its active level, and then holds it at that level until serviced. It ceases asserting the line when the CPU commands it to or otherwise handles the condition that caused it to signal the interrupt.

Level-triggered interrupts force firmware engineers to take into account what is generating the interrupt source. If the interrupt source is just a pulse from a state machine, then the device drivers do not need to do any additional work. If the interrupt source is asserted when a counter equals zero, the device driver must first write a non-zero value to the counter before it can acknowledge the interrupt. If the interrupt source is a signal from a different block with its own device driver or an external device under its own firmware control the device driver has no control over when the interrupt source is cleared. Its only choice is to disable that interrupt so that it can exit the interrupt handler.

There are also serious problems with sharing level-triggered interrupts. As long as any device on the line has an outstanding request for service the line remains asserted, so it is not possible to detect a change in the status of any other device. Deferring servicing a low-priority device is not an option, because this would prevent detection of service requests from higher-priority devices. If there is a device on the line that the CPU does not know how to service, then any interrupt from that device permanently blocks all interrupts from the other devices.