1) Base of hexadecimal number system? Answer : 16 2) Universal gate in digital logic? Answer : NAND 3) Memory type that is non-volatile? Answer : ROM 4) Basic building block of digital circuits? Answer : Gate 5) Device used for data storage in sequential circuits? Answer : Flip-flop 6) Architecture with shared memory for instructions and data? Answer : von Neumann 7) The smallest unit of data in computing? Answer : Bit 8) Unit that performs arithmetic operations in a CPU? Answer : ALU 9) Memory faster than main memory but smaller in size? Answer : Cache 10) System cycle that includes fetch, decode, and execute? Answer : Instruction 11) Type of circuit where output depends on present input only? Answer : Combinational 12) The binary equivalent of decimal 10? Answer : 1010 13) Memory used for high-speed temporary storage in a CPU? Answer : Register 14) Method of representing negative numbers in binary? Answer : Two's complement 15) Gate that inverts its input signal? Answer : NOT 16)...
Deadlock Characterization
Necessary Conditions:
There are four conditions that are required to achieve deadlock:
Mutual Exclusion - At least one resource must be grip in a non-sharable mode; If any other process requests this resource, then that process must wait for the resource to be released.
Hold and Wait - A process must be concurrently gripping at least one resource and waiting for at least one resource that is presently being grip by some other process.
No preemption - Once a process is belonging a resource ( i.e. once its request has been allowed ), then that resource not be taken away from that process until the process freely releases it.
Circular Wait - A group of processes { P0, P1, P2, . . ., PN } must exist such that every P[ i ] is waiting for P[ ( i + 1 ) % ( N + 1 ) ]. ( Note that this situation implied the hold-and-wait condition, but it is easier to deal with the conditions if the four are considered individually. )
Resource-Allocation Graph
In some cases deadlocks can be register more clearly through the use of Resource-Allocation Graphs, having the following properties:
*A group of resource categories, { R1, R2, R3, . . ., RN }, which looks as square nodes on the graph. Dots inside the resource nodes implicate specific instances of the resource. ( E.g. two dots might consider two laser printers. )
*A group of processes, { P1, P2, P3, . . ., PN }
*Request Edges - A group of directed arcs from Pi to Rj, indicating that process Pi has requested Rj, and is presently waiting for that resource to become obtainable.
*Assignment Edges - A group of directed arcs from Rj to Pi implies that resource Rj has been assigned to process Pi, and that Pi is presently holding resource Rj.
Note that a request edge can be transferred into an assignment edge by reversing the direction of the arc when the request is allowed. ( However note also that request edges point to the classification box, whereas assignment edges begin from a particular instance dot within the box. )
For example:
*If a resource-allocation graph has no cycles, then the system is not deadlocked. ( When looking for cycles, recollect that these are directed graphs. ) See the example in Fig above.
*If a resource-allocation graph does consist cycles AND each resource category contains only a single instance, then a deadlock exists.
*If a resource groups contains more than one occasion, then the presence of a cycle in the resource-allocation graph indicates the possibility of a deadlock, but does not guarantee one.
Methods for Handling Deadlocks
Normally speaking there are three types of handling deadlocks:
Deadlock prevention or avoidance - Do not permit the system to get into a deadlocked state.
Deadlock detection and recovery - End a process or preempt some resources when deadlocks are detected.
Ignore the problem all together - If deadlocks only happen once a year or so, it may be better to simply let them happen and restart as necessary than to attract the constant overhead and system performance penalties associated with deadlock preventing or detecting. This is the method that both Windows and UNIX take.
In order to prevent deadlocks, the system must have additional information about all processes. In particular, the system must know what resources a process will or may request in the future. ( Ranging
from a simple worst-case maximum to a complete resource request and release plan for each process, depending on the particular algorithm. )
Deadlock detection is fairly straightforward, but deadlock retrieval requires either ending processes or preventing resources, neither of which is an attractive alternative.
If deadlocks are neither detected nor prevented, then when a deadlock happens the system will gradually slow down, as more and more processes become stuck waiting for resources currently held by the deadlock and by other waiting processes. Unfortunately this slowdown can be identical from a general system slowdown when a real-time process has heavy computing needs.