<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mrshah2</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mrshah2"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Mrshah2"/>
	<updated>2026-09-12T04:09:19Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61682</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61682"/>
		<updated>2012-04-09T22:27:22Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines International Business Machines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:Thin Locks1.png|thumb|right|450px|Thin Locks Example]]&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
As shown in figure, consider a thin lock entry for a block which is initially not acquired by any thread.&lt;br /&gt;
&lt;br /&gt;
Thread A requests access to the block. As the lock is not acquired by any other thread, Thread A is granted access and Reserved bit is set to one. The recursion value is still zero as there is no recursion.&lt;br /&gt;
&lt;br /&gt;
Thread A re enters the same code block and requests to access the block. The lock is already acquired by Thread A, hence it is granted access to the block and recursion count is incremented to one - denotes that Thread A has acquired the lock twice.&lt;br /&gt;
&lt;br /&gt;
This is followed by a request from Thread B to access the same block. As thread A has the lock, thread B is not granted access and is placed in the entry code to wait till the Thread A releases the lock.&lt;br /&gt;
&lt;br /&gt;
Thread A releases the lock twice to decrement the recursion count and finally release the lock thus resetting the Reserved bit to zero. On this release, Thread B is allowed to acquire the lock. As there is a contention on the lock, the contention bit is set to 1 and the lock is inflated to a fat lock. Here the Fat Lock ID points to the Fat Lock in the fat lock table which is now acquired by Thread B. The lock count in the fat lock is incremented to one and denotes that Thread B has acquired it once.&lt;br /&gt;
&lt;br /&gt;
When Thread B releases the lock, the lock count in the fat lock is decremented to zero. Thus the lock is now free to use by any other thread. It is to be noted that the lock stays inflated now onward.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multiprocessing '''MP''']: Multiprocessing is the use of two or more central processing units (CPUs) within a single computer system.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61681</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61681"/>
		<updated>2012-04-09T22:25:12Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines International Business Machines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
[[Image:Thin Locks1.png|thumb|right|450px|Thin Locks Example]]&lt;br /&gt;
&lt;br /&gt;
As shown in figure, consider a thin lock entry for a block which is initially not acquired by any thread.&lt;br /&gt;
&lt;br /&gt;
Thread A requests access to the block. As the lock is not acquired by any other thread, Thread A is granted access and Reserved bit is set to one. The recursion value is still zero as there is no recursion.&lt;br /&gt;
&lt;br /&gt;
Thread A re enters the same code block and requests to access the block. The lock is already acquired by Thread A, hence it is granted access to the block and recursion count is incremented to one - denotes that Thread A has acquired the lock twice.&lt;br /&gt;
&lt;br /&gt;
This is followed by a request from Thread B to access the same block. As thread A has the lock, thread B is not granted access and is placed in the entry code to wait till the Thread A releases the lock.&lt;br /&gt;
&lt;br /&gt;
Thread A releases the lock twice to decrement the recursion count and finally release the lock thus resetting the Reserved bit to zero. On this release, Thread B is allowed to acquire the lock. As there is a contention on the lock, the contention bit is set to 1 and the lock is inflated to a fat lock. Here the Fat Lock ID points to the Fat Lock in the fat lock table which is now acquired by Thread B. The lock count in the fat lock is incremented to one and denotes that Thread B has acquired it once.&lt;br /&gt;
&lt;br /&gt;
When Thread B releases the lock, the lock count in the fat lock is decremented to zero. Thus the lock is now free to use by any other thread. It is to be noted that the lock stays inflated now onward.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multiprocessing '''MP''']: Multiprocessing is the use of two or more central processing units (CPUs) within a single computer system.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Thin_Locks1.png&amp;diff=61680</id>
		<title>File:Thin Locks1.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Thin_Locks1.png&amp;diff=61680"/>
		<updated>2012-04-09T22:24:37Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: Thin Locks example&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Thin Locks example&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61679</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61679"/>
		<updated>2012-04-09T22:23:58Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines International Business Machines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
[[Image:Thin Locks1.png|thumb|right|500px|Thin Locks Example]]&lt;br /&gt;
&lt;br /&gt;
As shown in figure, consider a thin lock entry for a block which is initially not acquired by any thread.&lt;br /&gt;
&lt;br /&gt;
Thread A requests access to the block. As the lock is not acquired by any other thread, Thread A is granted access and Reserved bit is set to one. The recursion value is still zero as there is no recursion.&lt;br /&gt;
Thread A re enters the same code block and requests to access the block. The lock is already acquired by Thread A, hence it is granted access to the block and recursion count is incremented to one - denotes that Thread A has acquired the lock twice.&lt;br /&gt;
This is followed by a request from Thread B to access the same block. As thread A has the lock, thread B is not granted access and is placed in the entry code to wait till the Thread A releases the lock.&lt;br /&gt;
Thread A releases the lock twice to decrement the recursion count and finally release the lock thus resetting the Reserved bit to zero. On this release, Thread B is allowed to acquire the lock. As there is a contention on the lock, the contention bit is set to 1 and the lock is inflated to a fat lock. Here the Fat Lock ID points to the Fat Lock in the fat lock table which is now acquired by Thread B. The lock count in the fat lock is incremented to one and denotes that Thread B has acquired it once.&lt;br /&gt;
When Thread B releases the lock, the lock count in the fat lock is decremented to zero. Thus the lock is now free to use by any other thread. It is to be noted that the lock stays inflated now onward.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multiprocessing '''MP''']: Multiprocessing is the use of two or more central processing units (CPUs) within a single computer system.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61678</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61678"/>
		<updated>2012-04-09T21:56:10Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines International Business Machines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
[[Image:Thin Locks.png|thumb|right|500px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multiprocessing '''MP''']: Multiprocessing is the use of two or more central processing units (CPUs) within a single computer system.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Thin_Locks.png&amp;diff=61677</id>
		<title>File:Thin Locks.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Thin_Locks.png&amp;diff=61677"/>
		<updated>2012-04-09T21:50:04Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: Thin Locks Example&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Thin Locks Example&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61676</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61676"/>
		<updated>2012-04-09T20:13:56Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Thin Lock  http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines International Business Machines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multiprocessing '''MP''']: Multiprocessing is the use of two or more central processing units (CPUs) within a single computer system.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61663</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61663"/>
		<updated>2012-04-09T17:44:45Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Glossary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multiprocessing '''MP''']: Multiprocessing is the use of two or more central processing units (CPUs) within a single computer system.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61661</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61661"/>
		<updated>2012-04-09T17:41:13Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Glossary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multiprocessing '''MP''']: Multiprocessing is the use of two or more central processing units (CPUs) within a single computer system.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61659</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61659"/>
		<updated>2012-04-09T17:39:27Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Glossary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Compare_and_swap '''CAS''']: Compare-and-swap (CAS) is an atomic CPU instruction used in multithreading to achieve synchronization.&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*'''MP''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61658</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61658"/>
		<updated>2012-04-09T17:38:15Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*'''LL/SC''': Load-linked/Store-Conditional&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Test-and-set '''test-and-set''']: It is an instruction used to write to a memory location and return its old value as a single atomic (i.e., non-interruptible) operation&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Mutual_exclusion '''mutual exclusion''']: It refers to the problem of ensuring that no two processes or threads (henceforth referred to only as processes) can be in their critical section at the same time.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) '''multi-threading''']: Multithreading computers have hardware support to efficiently execute multiple threads.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Java_virtual_machine '''JVM''']: A Java virtual machine (JVM) is a virtual machine capable of executing Java bytecode.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Monitor_(synchronization) '''monitor''']: A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Symmetric_multiprocessing '''SMP''']: Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance&lt;br /&gt;
*'''CAS''':&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/MESI '''MESI''']: The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol. It is the most common protocol which supports write-back cache.&lt;br /&gt;
*'''MP''':&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Just-in-time_compilation '''JIT''']: Just-in-time compilation, also known as dynamic translation, is a method to improve the runtime performance of computer programs.&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61657</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61657"/>
		<updated>2012-04-09T17:26:49Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Glossary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*'''LL/SC''':&lt;br /&gt;
*'''test-and-set''':&lt;br /&gt;
*'''mutual exclusion''':&lt;br /&gt;
*'''multi-threading''':&lt;br /&gt;
*'''JVM''':&lt;br /&gt;
*'''monitor - from the text only''':&lt;br /&gt;
*'''synchronized''':&lt;br /&gt;
*'''SMP''':&lt;br /&gt;
*'''CAS''':&lt;br /&gt;
*'''QRL''':&lt;br /&gt;
*'''MESI''':&lt;br /&gt;
*'''MP''':&lt;br /&gt;
*'''JIT''':&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61656</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61656"/>
		<updated>2012-04-09T17:25:05Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Glossary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Glossary==&lt;br /&gt;
LL/SC&lt;br /&gt;
test-and-set&lt;br /&gt;
mutual exclusion&lt;br /&gt;
multi-threading&lt;br /&gt;
JVM &lt;br /&gt;
monitor - from the text only&lt;br /&gt;
synchronized&lt;br /&gt;
SMP&lt;br /&gt;
CAS&lt;br /&gt;
QRL&lt;br /&gt;
MESI &lt;br /&gt;
MP&lt;br /&gt;
JIT&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61655</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61655"/>
		<updated>2012-04-09T15:45:22Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Glossary==&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;br /&gt;
&lt;br /&gt;
==Quiz==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61654</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61654"/>
		<updated>2012-04-09T15:32:33Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* See Also */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Glossary==&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;br /&gt;
&lt;br /&gt;
9. Concurrency in Java - http://jeremymanson.blogspot.com/2007/08/atomicity-visibility-and-ordering.html&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61653</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61653"/>
		<updated>2012-04-09T15:19:25Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* See Also */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Glossary==&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61652</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61652"/>
		<updated>2012-04-09T15:18:06Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;ref&amp;gt; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Glossary==&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
&lt;br /&gt;
1. Locking and Synchronization in Java - http://www.artima.com/insidejvm/ed2/threadsynch.html&lt;br /&gt;
2. C.A.R. Hoare, &amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&lt;br /&gt;
3. Java Tech: The ABCs of Synchronization - http://today.java.net/pub/a/today/2004/08/02/sync1.html&lt;br /&gt;
4. Synchronization in Java - http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&lt;br /&gt;
5. Kiyokuni Kawachiya, &amp;quot;Java Locks: Analysis and Acceleration&amp;quot; - http://www.research.ibm.com/trl/people/kawatiya/Kawachiya05phd.pdf&lt;br /&gt;
6. Thin Locks - http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&lt;br /&gt;
7. Biased Locks - http://home.comcast.net/~pjbishop/Dave/QRL-OpLocks-BiasedLocking.pdf&lt;br /&gt;
8. http://www.cs.man.ac.uk/~irogers/Reducing_Biased_Lock_Revocation_By_Learning.pdf&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61651</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61651"/>
		<updated>2012-04-09T15:10:13Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;lt;ref http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&amp;gt; &amp;quot;&amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a synchronized method &amp;lt;ref&amp;gt; http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html &amp;lt;/ref&amp;gt; or a synchronized statement &amp;lt;ref&amp;gt; http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Glossary==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61650</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61650"/>
		<updated>2012-04-09T15:04:34Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;lt;ref http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&amp;gt; &amp;quot;&amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a &amp;lt;ref http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html&amp;gt; synchronized method &amp;lt;/ref&amp;gt; or a &amp;lt;ref http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml&amp;gt; synchronized statement &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Glossary==&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61649</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61649"/>
		<updated>2012-04-09T15:01:33Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;lt;ref http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&amp;gt; &amp;quot;&amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a &amp;lt;ref http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html&amp;gt; synchronized method &amp;lt;/ref&amp;gt; or a &amp;lt;ref http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml&amp;gt; synchronized statement &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CAS) instruction 1 billion times to a thread-private location, and measure the elapsed time. &lt;br /&gt;
&lt;br /&gt;
If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. &lt;br /&gt;
&lt;br /&gt;
The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. &lt;br /&gt;
&lt;br /&gt;
It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. &lt;br /&gt;
&lt;br /&gt;
Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61648</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=61648"/>
		<updated>2012-04-09T14:53:46Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;p style=&amp;quot;font-size: 24px&amp;quot;&amp;gt;'''Reducing locking overhead'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Introduction==&lt;br /&gt;
The cost of locking is not only the cost of executing the hardware instructions (such as test-and-set or LL/SC), but also the associated software overhead of creating a monitor, and the system call for acquiring the actual lock. The [http://en.wikipedia.org/wiki/Mutual_exclusion mutual exclusion] problem arises in an activity wherein each participating process executes, in strict cyclic order, program regions labeled remainder, acquire, critical section, and then release. This mutual exclusion problem has a long history. A solution to the mutual exclusion problem consists of code for the acquire() and release() operation, which ensures that only one process is executing the critical section at any given time and no other process will complete an acquire() operation before the rest process invokes a release() operation. Solutions to the mutual exclusion problem are often referred to as locks.&lt;br /&gt;
&lt;br /&gt;
==Synchronization in Java==&lt;br /&gt;
&lt;br /&gt;
The support for [http://en.wikipedia.org/wiki/Multithreading_(computer_architecture) multi-threading] at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
To limit memory overhead, the Java runtime system kept information about locked objects in a (software) table, called a monitor cache.  Access to this cache needed to be serialized too.  This meant that as the program used more locks, performance got worse and worse. &lt;br /&gt;
&lt;br /&gt;
=== Memory Model for Data===&lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has its own [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Stack.html Java stack]. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
=== Sharing and Locks===&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differs from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
=== Monitors=== &lt;br /&gt;
&lt;br /&gt;
The [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  uses locks in conjunction with [monitors. A [http://en.wikipedia.org/wiki/Monitor_(synchronization) monitor] is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. &lt;br /&gt;
They combine the below three features,&lt;br /&gt;
* Shared data.&lt;br /&gt;
* Operations on the data.&lt;br /&gt;
* Synchronization, scheduling.&lt;br /&gt;
They are especially convenient for synchronization involving lots of state. Compare monitors to modules and abstract data types. Monitors are embedded in some concurrent programming languages. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
In the style of C, a queue manipulation monitor might look like:&amp;lt;ref&amp;gt;http://courses.mpi-sws.org/os-ss11/lectures/proc5.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 monitor QueueHandler;&lt;br /&gt;
 struct {&lt;br /&gt;
 int add, remove, buﬀer[200];&lt;br /&gt;
 } queue;&lt;br /&gt;
 void AddToQueue(int val)&lt;br /&gt;
 { – add val to end of queue – }&lt;br /&gt;
 int RemoveFromQueue()&lt;br /&gt;
 { – remove value from queue, return it – }&lt;br /&gt;
 end monitor&lt;br /&gt;
&lt;br /&gt;
===  Synchronization&amp;lt;ref&amp;gt;http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html?page=1&amp;lt;/ref&amp;gt;=== &lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
The Java Memory Model says that one thread exiting a synchronized block happens-before another thread enters a synchronized block protected by that same lock; this means that whatever memory operations are visible to thread A when it exits a synchronized block protected by lock M are visible to thread B when it enters a synchronized block protected by M, as shown in the adjacent figure&lt;br /&gt;
&amp;lt;ref&amp;gt;http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Sync.png|thumb|right|350px|Synchronization and visibility in the Java Memory Model]]&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''[http://en.wikipedia.org/wiki/Synchronization_(computer_science) synchronized]'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'', are used while entering and exiting the synchronized block. When the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM]  encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;lt;ref http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&amp;gt; &amp;quot;&amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a &amp;lt;ref http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html&amp;gt; synchronized method &amp;lt;/ref&amp;gt; or a &amp;lt;ref http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml&amp;gt; synchronized statement &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
==Thin Lock  &amp;lt;ref&amp;gt;http://www.research.ibm.com/people/d/dfb/papers/Bacon98Thin.pdf&amp;lt;/ref&amp;gt;== &lt;br /&gt;
In Java methods of an object can be declared as synchronized, which implies that the object must be locked for the duration of method s execution. But there is a substantial performance degradation when in the absence of any true concurrency. One of the way to speed up the synchronization is by dedicating a portion of each object as a lock. Hence all objects in Java are potential locks (monitors). This potential is realized as an actual lock as soon as any thread enters a synchronized block on that object. When a lock is created in this way, it is a kind of lock that is known as a &amp;quot;thin lock.&amp;quot; &lt;br /&gt;
&lt;br /&gt;
Thin Locks were invented by compiler genius DavidBacon, of [http://c2.com/cgi/wiki?InternationalBusinessMachines InternationalBusinessMachines], and have been much played with and improved on since then.&lt;br /&gt;
&lt;br /&gt;
===Characteristics===&lt;br /&gt;
A thin lock has the following characteristics:&lt;br /&gt;
*Speed:These locks are fast for uncontended acquisitions, which are the most common case in many situations. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization. In the absence of any contention, the initial locking and nested locking are very fast as it has only few machine instructions and during the presence of any contention it still performs better. &lt;br /&gt;
&lt;br /&gt;
*Compactness:  It doesn't requires no extra memory—all information about the lock as it is stored in the object itself. Only 24 bits of the object are used for locking and other compression techniques ensure that this doesn't have an impact on the size of the object. &lt;br /&gt;
&lt;br /&gt;
*Scalability:  Usage of global locks and synchronization instructions that are used to broadcast the changes to global bus are kept to an absolute minimum, which in turn results in effective execution on large multiprocessors.&lt;br /&gt;
&lt;br /&gt;
*Maintainability: Thin lock code is portable assuming that it consists only CAS instructions.&lt;br /&gt;
&lt;br /&gt;
===Algorithm===&lt;br /&gt;
&lt;br /&gt;
As said earlier for locks that are mostly uncontended, thin locks are efficient. There is little overhead compared to no locking, which is good since a lot of Java code (especially in the class library) use lot of synchronization.&lt;br /&gt;
&lt;br /&gt;
But, as soon as a lock becomes contended, the situation is no longer as obvious as to what is most efficient. If a lock is held for just a very short moment of time, and [http://en.wikipedia.org/wiki/JRockit JRockit] is running on a multi-CPU (SMP) machine, then the best strategy is to &amp;quot;spin-lock.&amp;quot; This means that the thread that wants to acquire the lock continuously checks if the lock is still taken, &amp;quot;spinning&amp;quot; in a tight loop. This of course means some performance loss: as there is no actual user code that is running during this duration, and the CPU is wasting time that could have been spent on other threads. Still this method is preferable, if the lock is released by the other threads after just a few cycles in the spin loop. This is what's meant by a contended thin lock &lt;br /&gt;
&lt;br /&gt;
Let us consider all the cases in order to optimize the Java's locking performance. Below is the list of all the cases with each being less common compared to the case preceding it,&lt;br /&gt;
&lt;br /&gt;
*Locking an object, which is unlocked.&lt;br /&gt;
*Locking an object, which is already locked by the current thread a small number of times i.e. which is referred to as Shallowly nested locking.&lt;br /&gt;
*Locking an object, which is already locked by the current thread many times i.e. which is referred to as Deeply nested locking.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which no other threads are waiting.&lt;br /&gt;
*Attempting to lock an object, which is already locked by another thread, for which other threads are waiting.&lt;br /&gt;
&lt;br /&gt;
Let us assume that thin locks consist of only &amp;quot;compare-and-swap&amp;quot; atomic instruction. In general compare-and-swap instruction takes only three inputs - an address, old value and a new value. If the content of the address matches the old value then the new value is stored in the address and true is returned. Else the address content remains unchanged and false is returned.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using the encoding techniques we are able to obtain 24 free bits of the header, which are reserved in order to implement the thin locks as shown in the below figures. The basic structure of a thin lock word is shown in the adjacent for the first instance of lock acquiring etc..The lock bits either refer to the thin lock or flat lock. The '0' corresponds to the thin lock where as the '1' represents the flat lock &amp;lt;ref&amp;gt;http://harmony.apache.org/subcomponents/drlvm/TM.html&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In the absence of contention, the lock type is zero, and the lock word has the following structure:&lt;br /&gt;
[[Image:Cont0.png|thumb|center|600px|Lock Word Structure: Contention Bit is 0]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit : 0 indicating that absence of contention&lt;br /&gt;
*Thread ID (15 bits): the ID of the owning thread, or 0 if the lock is free&lt;br /&gt;
*Recursion count: the number of times that the lock has been acquired by the same thread minus 1&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
In the presence of contention, the contention bit is set to 1, and a thin compressed lock becomes a fat inflated lock with the following figure:&amp;lt;ref&amp;gt;http://dl.acm.org/citation.cfm?id=582433&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cont1.png|thumb|center|600px|Lock Word Structure: Contention Bit is 1]]&lt;br /&gt;
&lt;br /&gt;
In the above figure,&lt;br /&gt;
*Contention bit: 1 indicating presence of contention&lt;br /&gt;
*Fat Lock ID (20 bits): the ID of the corresponding fat lock&lt;br /&gt;
*Reservation bit: the flag indicating whether the lock is reserved by a thread.&lt;br /&gt;
*Rightmost 10 bits unused in TM and reserved for storing the hash codes of Java* objects&lt;br /&gt;
&lt;br /&gt;
This method on contention would lead to bad performance if the lock is not going to be released very fast. In this case, the lock is &amp;quot;inflated&amp;quot; to a &amp;quot;fat lock.&amp;quot; A fat lock has the following characteristics: It requires a little extra memory, in terms of a separate list of threads wanting to acquire the lock and It is relatively slow to take and One (or more) threads can register as queuing for (blocking on) that lock. A thread that encounters contention on a fat lock register itself as blocking on that lock, and goes to sleep. This means giving up the rest of its time quantum given to it by the OS. While this means that the CPU will be used for running real user code on another thread, the extra context switch is still expensive, compared to spin locking. When a thread does this, we have a &amp;quot;contended fat lock.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Whenever the last contending thread releases a fat lock, the lock normally remains fat. Taking this fat lock, even without contention, is more expensive than taking a fat lock (but less expensive than converting a thin lock to a fat lock). If JRockit believes that the lock would benefit from being thin (basically, if the contention was pure &amp;quot;bad luck&amp;quot; and the lock normally is uncontended), it might &amp;quot;deflate&amp;quot; it to a thin lock again. A special note regarding locks is that: if a wait/notify/notifyAll is called on a lock, it will automatically inflate to a fat lock. So a good practice (not only for this reason) is therefore not to mix actual locking with this kind of notification on a single object.&lt;br /&gt;
&lt;br /&gt;
The monitor acquiring process with the help of the &amp;quot;hythread_thin_monitor_try_enter()&amp;quot; function is shown on the following diagram:&lt;br /&gt;
&lt;br /&gt;
[[Image:Lock reservation.gif|thumb|center|600px|Process of acquiring the thin lock]]&lt;br /&gt;
&lt;br /&gt;
At the starting, the thread uses the reservation bit to check whether the required lock is owned by this thread. If yes, the thread increases the recursion count by 1 and exits the function. This makes the fast path of the monitor enter operation for a single-threaded application. The fast path involves only a few assembly instructions and does no expensive atomic compare-and-swap (CAS) operations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the lock is not yet been reserved, then it is checked for being occupied. The free lock is set to be reserved and acquired simultaneously with a single CAS operation. If the lock becomes busy then, the system checks whether the lock is fat.&lt;br /&gt;
&lt;br /&gt;
The lock table holds a mapping between the fat lock ID and the actual monitor. Fat monitors are extracted from the lock table and acquired. If the lock is not fat and reserved by another thread, then this thread suspends the execution of the lock owner thread, removes the reservation, and resumes the owner thread. After that, the lock acquisition is tried again.&lt;br /&gt;
&lt;br /&gt;
== Biased Lock ==&lt;br /&gt;
&lt;br /&gt;
Biased locks are an optimization over thin locks.  Biased locking takes advantage of the empirically known fact that most locks are only acquired by a single thread during their lifetime.  This allows a thread to never actually give up the lock on &amp;quot;lock release.&amp;quot;  The next time the same thread tries to acquire the lock, it will find that it already owns the lock.  This saves the owner thread the additional synchronization instruction (e.g., LL/SC) when it attempts to acquire the lock after the first time.  Thus, this particular lock is &amp;quot;biased&amp;quot; towards the owner thread.  The lock is inflated into a thick lock and the bias is &amp;quot;revoked,&amp;quot; if a non-owner thread attempts to acquire a biased lock, since now there is another thread interested in acquiring this lock.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In all the algorithms discussed above consists of atomic instructions like compare-and-swap operations. Considering that atomic operations are especially expensive (memory fence on modern hardware - i.e. need to flush memory queues) in modern architectures, they are becoming the major overhead factor in Java locks. The atomic operations are very eﬀective in the situation where multiple threads acquire a lock symmetrically. But in general this is not the best solution when there is an asymmetry in the lock acquisitions. This case is very common in an important class of applications that includes such systems as Java Virtual Machines. If an object’s lock is frequently acquired by a speciﬁc thread, the lock’s cost may be further reduced by giving a certain precedence to that thread, while shifting costs to other threads. This optimized technique is known as quickly reacquirable mutual exclusion locks (QRLs) or Biased locking or Reservation Lock.&lt;br /&gt;
&lt;br /&gt;
===Algorithm&amp;lt;ref&amp;gt;https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
To make this optimized technique eﬀective, there must exist a locality such that each object’s lock is frequently acquired by a speciﬁc thread, for which the lock is to be reserved. This locality is known as thread locality and it is defined in terms of the lock sequence, the sequence of threads (in temporal order) that acquire the lock. The key idea is to allow a lock to be reserved for a thread. The reservation-owner thread can perform the lock processing without atomic operations, so the lock overhead is minimized. If another thread attempts to acquire the reserved lock, the reservation must ﬁrst be canceled, and the lock processing falls back to an existing algorithm. For a given lock, if its lock sequence contains a very long repetition of a&lt;br /&gt;
speciﬁc thread, the lock is said to exhibit thread locality, while the speciﬁc thread is said to be the dominant locker.&lt;br /&gt;
&lt;br /&gt;
The Reservation lock mechanism can be explained in detail as below. The key idea of this algorithm is to reserve locks for threads. When a thread attempts&lt;br /&gt;
to acquire an object’s lock, one of the following actions is taken in accordance with the lock’s reservation status:&lt;br /&gt;
* If the object’s lock is reserved for the thread, the runtime system allows the thread to acquire the lock with a few instructions involving no atomic operations.&lt;br /&gt;
* If the object’s lock is reserved for another thread, the runtime system cancels the reservation, and falls back to a conventional algorithm for further processing.&lt;br /&gt;
* If the object’s lock is not reserved, or the reservation was already canceled, the runtime system uses a conventional algorithm.&lt;br /&gt;
&lt;br /&gt;
If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either&lt;br /&gt;
rebias the object or simply revert to normal locking for the remainder of the object's lifetime).Revocation must suspend a thread to scan its stack - or ask the thread to do it itself. The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread).we must ensure that the revokee doesn't lock or unlock the object during revocation.&lt;br /&gt;
&lt;br /&gt;
The QRL is strictly in response to the latency of compare-and-swap (CAS). It is important to note that CAS incurs local latency, but does not impact scalability on the modern processors. A common assumption is that each CAS operation &amp;quot;goes on the bus&amp;quot;, and, given that the interconnect is a fixed a contended resource, use of CAS can impair scalability. This assumption is false. &lt;br /&gt;
The CAS can be accomplished locally, with no bus transactions, if the line is already in M-state. CAS is usually implemented on top of the existing MESI snoop-based cache coherence protocol, but in terms of the bus, CAS is no different than a store.&lt;br /&gt;
 &lt;br /&gt;
===Example:===  &lt;br /&gt;
Let us assume that we have a true 16-way system. We launch a thread that executes the compare-and-swap (CASes) instruction 1 billion times to a thread-private location, and measure the elapsed time. If we then launch 16 threads, all CASing to thread-private locations, the elapsed time will be the same. The threads don't interfere with or impede each other in any way. Even if we launch 16 threads all CASing to the same location we will typically see a massive slow-down because of interconnect traffic. (The sole exception to that claim is Sun's Niagara, which can gracefully tolerate sharing on a massive scale as the L2$ serves as the interconnect). If we then change that CAS to a normal store we will also see a similar slow-down; as noted before, in terms of coherency bus traffic, CAS isn't appreciably different than a normal store. Some of the misinformation regarding CAS probably arises from the original implementation of lock:cmpxchg (CAS) on Intel processors. The lock: prefix caused the LOCK# signal to be asserted, acquiring exclusive access to the bus. This didn't scale of course. Subsequent implementations of lock:cmpxchg leverage cache coherency protocol -- typically snoop-based MESI -- and don't assert LOCK#. Note that lock:cmpxchg will still drive LOCK# in one extremely exotic case -- when the memory address is misaligned and spans 2 cache lines. Finally, we can safely use cmpxchg on uniprocessors but must use lock:cmpxchg on multiprocessor systems. Lock:cmpxchg incurs more latency, but then again it's a fundamentally different instruction that cmpxchg. Lock:cmpxchg is serializing, providing bidirectional mfence-equivalent semantics. (Fence or barrier instructions are never needed for uniprocessors) This fact might also have contributed to the myth that CAS is more expensive on MP systems. But of course lock:cmpxchg incurs no more latency on a 2x system than on an 8x system.&lt;br /&gt;
&lt;br /&gt;
And on bus operations, let us assume that a load is followed closely in program order by a store or CAS to the same cache line. If the cache line is not present in the issuing processor then the load will generate a request-to-share transaction to get the line in S-state and the store or CAS will result in a subsequent request-to-own transaction to force the line into M-state. This second transaction can be avoided on some platforms by using a prefetch-for-write instruction before the load, which will force the line directly into M-state. It's also worth mentioning that on typical classic SMP systems, pure read-sharing is very efficient. All the requesting processors can have the cache line(s) replicated in their caches. But if even one processor is writing to a shared cache line, those writes will generate considerable cache coherence traffic; assuming a write-invalidate cache coherence policy (as opposed to write-update) the readers will continually re-load the cache line just to have it subsequently invalidated by the writer(s). Put differently, loads to a cache line are cheap if other processors are loading from but not storing to that same line. Stores are cheap only if no other processors are concurrently storing to or loading from that same line. (We can draw an imprecise analogy between cache coherency protocols and read-write locks in that for a given cache line there can only be one writer at any given time. That's the processor with the line in M-state. Multiple readers of the line allowed and of course the lifetime of a reader can't overlap a write. Unlike traditional read-write locks, however, the cache coherency protocol allows writers to invalidate readers, so we can't push the analogy too far. In a twisted sense, the coherency protocol is obstruction-free). Coherency bandwidth is a fixed and contended global resource, so in addition to local latency, excessive sharing traffic will impact overall scalability and impede the progress of threads running on other processors. A so-called coherency miss -- for example a load on processor P1 where processor P2 has the cache line in M-state -- is typically much slower than a normal miss (except on Niagara). Recall too, that acquiring a lock involves a store (CAS, really) to the lock metadata, so if you have threads on processors P1 and P2 iterating, acquiring the same, the lock acquisition itself will generate coherency traffic and result in the cache &amp;quot;sloshing&amp;quot; of the line(s) holding the metadata. Generally, excessive coherency traffic is to be avoided on classic SMP systems. But as usual, there's an exception to any rule, and in this case that exception is Sun's Niagara, which can tolerate sharing gracefully.&lt;br /&gt;
&lt;br /&gt;
==Conclusion==&lt;br /&gt;
The QRL locks are a novel class of mutual exclusion algorithms that are heavily optimized for a very common data access pattern in which a single process repeatedly and solely acquires a lock. The QRL locks represent the ﬁrst true atomic-free locks for this ultra fast path. Because they can be generalized to use any mutual exclusion algorithm with a standard interface, as well as many algorithms that do not use a standard interface, QRL locks can obtain the beneﬁts of any properties of such locks for the uncontended case at the expense of a mere handful of non-atomic instructions in their critical path. QRL locks are optimized for a single-process repeated-acquisition data access pattern; however, we have also demonstrated rebiasable QRLs that can be used with migratory data access patterns.&lt;br /&gt;
&lt;br /&gt;
Another approach to improve the performance of java locks by totally eliminating the locks rather than to reduce the cost of the locks. The most common eliminating techniques is to identify objects which are only accessible by their creator threads by using escape analysis and to eliminate all lock operations for such non-escaping objects. There are several techniques to eliminate recursive locks. For example when we incline one synchronize method in the other then the JIT compiler can eliminate the inner locks if it detects that the receiver objects of these methods are always identical.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=60926</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=60926"/>
		<updated>2012-04-03T12:42:54Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;1. Introduction&lt;br /&gt;
&lt;br /&gt;
2. Synchronization in Java&lt;br /&gt;
&lt;br /&gt;
The support for multi-threading at language level is the strength of Java programming language. Hence most of Java programming language is centered around coordinating the sharing of data among the multiple threads.&lt;br /&gt;
&lt;br /&gt;
2.1. Memory Model for Data&lt;br /&gt;
&lt;br /&gt;
The JVM organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area.&lt;br /&gt;
&lt;br /&gt;
Each thread has it own Java stack. The stack contains data that cannot be accessed by other threads (including the local variables, parameters, and return values of each method the thread has invoked). The data on the stack is limited to primitive types and object references. The JVM has only one heap which is shared by all threads. The heap contains objects. The Method Area is another place where data can reside. It contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.&lt;br /&gt;
&lt;br /&gt;
2.2. Sharing and Locks&lt;br /&gt;
&lt;br /&gt;
The sharing of data in a multiprocessor differ from that of the uniprocessor. In a uni-processor system, multiple threads do not execute concurrently but they time share the processor for execution. Whereas on multiprocessor, multiple threads execute concurrently on different processors. Thus they have a tight contention for locks and strong sharing rules on multi processor system.&lt;br /&gt;
&lt;br /&gt;
As mentioned above, the heap and the method area contain all the data that is shared by multiple threads. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can &amp;quot;possess&amp;quot; at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the JVM for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.&lt;br /&gt;
Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.&lt;br /&gt;
&lt;br /&gt;
2.3. Monitors&lt;br /&gt;
&lt;br /&gt;
The JVM uses locks in conjunction with monitors. A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.&lt;br /&gt;
&lt;br /&gt;
2.4. Synchronization&lt;br /&gt;
&lt;br /&gt;
A single thread is allowed to lock the same object multiple times. For each object, the JVM maintains a count of the number of times the object has been locked. An unlocked object has a count of zero. When a thread acquires the lock for the first time, the count is incremented to one. Each time the thread acquires a lock on the same object, a count is incremented. Each time the thread releases the lock, the count is decremented. When the count reaches zero, the lock is released and made available to other threads.&lt;br /&gt;
&lt;br /&gt;
For a java developer, the keyword ''synchronized'' is provided to enforce critical execution on a statement or a method. On entering a synchronized block, a lock is acquired. The block is not executed till a lock is acquired. The opcodes ''monitorenter'' and ''monitorexit'' are used while entering and exiting the synchronized block. When the JVM encounters monitorenter, it acquires the lock for the object referred. If the thread already owns the lock for the object, the lock count is incremented. Similarly, when monitorexit is executed by the JVM, the count is decremented. The monitor lock is released when the count reaches zero.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----- Still to be included -----------&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;lt;ref http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&amp;gt; &amp;quot;&amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a &amp;lt;ref http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html&amp;gt; synchronized method &amp;lt;/ref&amp;gt; or a &amp;lt;ref http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml&amp;gt; synchronized statement &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Thin Lock Mechanism&lt;br /&gt;
&lt;br /&gt;
Biased Lock Mechanism&lt;br /&gt;
&lt;br /&gt;
Conclusion&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=60925</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=60925"/>
		<updated>2012-04-03T11:38:27Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Introduction&lt;br /&gt;
&lt;br /&gt;
Synchronization in Java&lt;br /&gt;
&lt;br /&gt;
Sun's Java virtual machine specification states that synchronization is based on monitors. This point is reinforced at the Java VM level by the presence of ''monitorenter'' and ''monitorexit'' instructions.&lt;br /&gt;
&lt;br /&gt;
First suggested by E. W. Dijkstra in 1971, conceptualized by P. Brinch Hansen in 1972-1973, and refined by C. A. R. Hoare in 1974, a monitor is a concurrency construct that encapsulates data and functionality for allocating and releasing shared resources (such as network connections, memory buffers, printers, and so on). To accomplish resource allocation or release, a thread calls a monitor entry (a special function or procedure that serves as an entry point into a monitor). If there is no other thread executing code within the monitor, the calling thread is allowed to enter the monitor and execute the monitor entry's code. But if a thread is already inside of the monitor, the monitor makes the calling thread wait outside of the monitor until the other thread leaves the monitor. The monitor then allows the waiting thread to enter. Because synchronization is guaranteed, problems such as data&lt;br /&gt;
being lost or scrambled are avoided. To learn more about monitors, study Hoare's landmark paper, &amp;lt;ref http://john.cs.olemiss.edu/~dwilkins/Seminar/S05/Monitors.pdf&amp;gt; &amp;quot;&amp;quot;Monitors: An Operating System Structuring Concept,&amp;quot; &amp;lt;/ref&amp;gt; first published by the Communications of the Association for Computing Machinery Inc. in 1974.&lt;br /&gt;
&lt;br /&gt;
The Java virtual machine specification goes on to state that monitor behavior can be explained in terms of locks. Think of a lock as a token that a thread must acquire before a monitor allows that thread to execute inside of a monitor entry. That token is automatically released when the thread exits the monitor, to give another thread an opportunity to get the token and enter the monitor.&lt;br /&gt;
&lt;br /&gt;
Java associates locks with objects: each object is assigned its own lock, and each lock is assigned to one object. A thread acquires an object's lock prior to entering the lock-controlled monitor entry, which Java represents at the&lt;br /&gt;
source code level as either a &amp;lt;ref http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html&amp;gt; synchronized method &amp;lt;/ref&amp;gt; or a &amp;lt;ref http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml&amp;gt; synchronized statement &amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Thin Lock Mechanism&lt;br /&gt;
&lt;br /&gt;
Biased Lock Mechanism&lt;br /&gt;
&lt;br /&gt;
Conclusion&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=60924</id>
		<title>CSC/ECE 506 Spring 2012/9a ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/9a_ms&amp;diff=60924"/>
		<updated>2012-04-03T10:51:03Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: Created page with &amp;quot;Introduction  Monitors  Problems with Monitors  Thin Lock Mechanism  Biased Lock Mechanism  Conclusion&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Introduction&lt;br /&gt;
&lt;br /&gt;
Monitors&lt;br /&gt;
&lt;br /&gt;
Problems with Monitors&lt;br /&gt;
&lt;br /&gt;
Thin Lock Mechanism&lt;br /&gt;
&lt;br /&gt;
Biased Lock Mechanism&lt;br /&gt;
&lt;br /&gt;
Conclusion&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58174</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58174"/>
		<updated>2012-02-07T02:51:23Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Special-purpose systolic array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the [http://www.cs.cmu.edu/~iwarp/ CMU iWrap] [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann paradigm], instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7] and [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic-array-for-matrix-multiplication.gif the animation] created with the help from the [http://www.iti.fh-flensburg.de/lang/papers/isa/isa2.htm link]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_3.png Figure 8]) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_4.png Figure 9]) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf 5]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Reconfig.jpg Figure 10]. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Comp.png Figure 11] shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire Fly-By-Wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. [[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.[[Image:fig14.png|thumb|right|250px|Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Fig13.png Figure 13].&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*'''CMU''': Carnegie Mellon University&lt;br /&gt;
&lt;br /&gt;
*'''CU''': Control Unit&lt;br /&gt;
&lt;br /&gt;
*'''DS''': Data Stream&lt;br /&gt;
&lt;br /&gt;
*'''Fly-By-Wire''': System that replaces the conventional manual flight controls of an aircraft with an electronic interface&lt;br /&gt;
&lt;br /&gt;
*'''FPGA''': Field Programmable Gate Array&lt;br /&gt;
&lt;br /&gt;
*'''Heterogeneous Systems''': A multiprocessor system with different kind of processors&lt;br /&gt;
&lt;br /&gt;
*'''Homogeneous System''': A multiprocessor system with same kind of processors&lt;br /&gt;
&lt;br /&gt;
*'''ILP''': Instruction Level Parallelism&lt;br /&gt;
&lt;br /&gt;
*'''IS''': Instruction Stream&lt;br /&gt;
&lt;br /&gt;
*'''MIMD''': Multiple Instruction Multiple Data&lt;br /&gt;
&lt;br /&gt;
*'''MISD''': Multiple Instruction Single Data&lt;br /&gt;
&lt;br /&gt;
*'''PE''': Processing Element&lt;br /&gt;
&lt;br /&gt;
*'''PFC''': Primary Flight Computer&lt;br /&gt;
&lt;br /&gt;
*'''SAPO''': Short for Samočinný počítač&lt;br /&gt;
&lt;br /&gt;
*'''SIMD''': Single Instruction Multiple Data&lt;br /&gt;
&lt;br /&gt;
*'''SISD''': Single Instruction Single Data&lt;br /&gt;
&lt;br /&gt;
*'''VLSI''': Very Large Scale Integration&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58122</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58122"/>
		<updated>2012-02-06T22:58:04Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Glossary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the [http://www.cs.cmu.edu/~iwarp/ CMU iWrap] [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann paradigm], instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_3.png Figure 8]) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_4.png Figure 9]) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Reconfig.jpg Figure 10]. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Comp.png Figure 11] shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire Fly-By-Wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Fig13.png Figure 13].&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
*'''CMU''': Carnegie Mellon University&lt;br /&gt;
&lt;br /&gt;
*'''CU''': Control Unit&lt;br /&gt;
&lt;br /&gt;
*'''DS''': Data Stream&lt;br /&gt;
&lt;br /&gt;
*'''Fly-By-Wire''': System that replaces the conventional manual flight controls of an aircraft with an electronic interface&lt;br /&gt;
&lt;br /&gt;
*'''FPGA''': Field Programmable Gate Array&lt;br /&gt;
&lt;br /&gt;
*'''Heterogeneous Systems''': A multiprocessor system with different kind of processors&lt;br /&gt;
&lt;br /&gt;
*'''Homogeneous System''': A multiprocessor system with same kind of processors&lt;br /&gt;
&lt;br /&gt;
*'''ILP''': Instruction Level Parallelism&lt;br /&gt;
&lt;br /&gt;
*'''IS''': Instruction Stream&lt;br /&gt;
&lt;br /&gt;
*'''MIMD''': Multiple Instruction Multiple Data&lt;br /&gt;
&lt;br /&gt;
*'''MISD''': Multiple Instruction Single Data&lt;br /&gt;
&lt;br /&gt;
*'''PE''': Processing Element&lt;br /&gt;
&lt;br /&gt;
*'''PFC''': Primary Flight Computer&lt;br /&gt;
&lt;br /&gt;
*'''SAPO''': Short for Samočinný počítač&lt;br /&gt;
&lt;br /&gt;
*'''SIMD''': Single Instruction Multiple Data&lt;br /&gt;
&lt;br /&gt;
*'''SISD''': Single Instruction Single Data&lt;br /&gt;
&lt;br /&gt;
*'''VLSI''': Very Large Scale Integration&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58120</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58120"/>
		<updated>2012-02-06T22:50:40Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the [http://www.cs.cmu.edu/~iwarp/ CMU iWrap] [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann paradigm], instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_3.png Figure 8]) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_4.png Figure 9]) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Reconfig.jpg Figure 10]. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Comp.png Figure 11] shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire Fly-By-Wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Fig13.png Figure 13].&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=='''Glossary'''==&lt;br /&gt;
{{gloss}}&lt;br /&gt;
{{term|CMU}}&lt;br /&gt;
{{defn|1= Carnegie Mellon University.}}&lt;br /&gt;
&lt;br /&gt;
{{term|CU}}&lt;br /&gt;
{{defn|1= Control Unit.}}&lt;br /&gt;
&lt;br /&gt;
{{term|DS}}&lt;br /&gt;
{{defn|1= Data Stream.}}&lt;br /&gt;
&lt;br /&gt;
{{term|Fly-By-Wire}}&lt;br /&gt;
{{defn|1= system that replaces the conventional manual flight controls of an aircraft with an electronic interface.}}&lt;br /&gt;
&lt;br /&gt;
{{term|FPGA }}&lt;br /&gt;
{{defn|1= Field Programmable Gate Array.}}&lt;br /&gt;
&lt;br /&gt;
{{term|Heterogeneous Systems}}&lt;br /&gt;
{{defn|1= A multiprocessor system with different kind of processors.}}&lt;br /&gt;
&lt;br /&gt;
{{term|Homogeneous System }}&lt;br /&gt;
{{defn|1= A multiprocessor system with same kind of processors.}}&lt;br /&gt;
&lt;br /&gt;
{{term|ILP }}&lt;br /&gt;
{{defn|1= Instruction Level Parallelism.}}&lt;br /&gt;
&lt;br /&gt;
{{term|IS }}&lt;br /&gt;
{{defn|1= Instruction Stream.}}&lt;br /&gt;
&lt;br /&gt;
{{term|MIMD }}&lt;br /&gt;
{{defn|1= Multiple Instruction Multiple Data.}}&lt;br /&gt;
&lt;br /&gt;
{{term|MISD }}&lt;br /&gt;
{{defn|1= Multiple Instruction Single Data.}}&lt;br /&gt;
&lt;br /&gt;
{{term|PE }}&lt;br /&gt;
{{defn|1= Processing Element.}}&lt;br /&gt;
&lt;br /&gt;
{{term|PFC }}&lt;br /&gt;
{{defn|1= Primary Flight Computer.}}&lt;br /&gt;
&lt;br /&gt;
{{term|SAPO }}&lt;br /&gt;
{{defn|1= short for Samočinný počítač.}}&lt;br /&gt;
&lt;br /&gt;
{{term|SIMD }}&lt;br /&gt;
{{defn|1= Single Instruction Multiple Data.}}&lt;br /&gt;
&lt;br /&gt;
{{term|SISD }}&lt;br /&gt;
{{defn|1= Single Instruction Single Data.}}&lt;br /&gt;
&lt;br /&gt;
{{term|VLSI }}&lt;br /&gt;
{{defn|1= Very Large Scale Integration.}}&lt;br /&gt;
&lt;br /&gt;
{{glossend}}&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58119</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58119"/>
		<updated>2012-02-06T22:40:04Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* The Flight Control System – MISD Example for fault tolerance */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the [http://www.cs.cmu.edu/~iwarp/ CMU iWrap] [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann paradigm], instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_3.png Figure 8]) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_4.png Figure 9]) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Reconfig.jpg Figure 10]. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Comp.png Figure 11] shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire Fly-By-Wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Fig13.png Figure 13].&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58118</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58118"/>
		<updated>2012-02-06T22:39:34Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the [http://www.cs.cmu.edu/~iwarp/ CMU iWrap] [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann paradigm], instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_3.png Figure 8]) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD ([http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_4.png Figure 9]) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Reconfig.jpg Figure 10]. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Comp.png Figure 11] shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Fig13.png Figure 13].&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58117</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58117"/>
		<updated>2012-02-06T22:35:48Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Multiple Instructions, Single Data stream (MISD) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the [http://www.cs.cmu.edu/~iwarp/ CMU iWrap] [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann paradigm], instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58116</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58116"/>
		<updated>2012-02-06T22:34:42Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann paradigm], instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58115</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58115"/>
		<updated>2012-02-06T22:34:09Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Flynn’s Taxonomy of Parallel Computershttp://en.wikipedia.org/wiki/Flynn's_taxonomyhttp://www.phy.ornl.gov/csep/ca/node11.html */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58114</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58114"/>
		<updated>2012-02-06T22:31:59Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional [http://en.wikipedia.org/wiki/Von_Neumann_model von Neumann architecture]: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58111</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58111"/>
		<updated>2012-02-06T22:20:48Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* General-purpose systolic array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] re-configuring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both [http://en.wikipedia.org/wiki/Very-large-scale_integration VLSI] and [http://en.wikipedia.org/wiki/Field-programmable_gate_array FPGA] technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58110</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58110"/>
		<updated>2012-02-06T22:19:10Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Special-purpose systolic array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 7]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58109</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58109"/>
		<updated>2012-02-06T22:18:46Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Special-purpose systolic array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6] illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Systolic_1.png Figure 6]. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58108</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58108"/>
		<updated>2012-02-06T22:15:16Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Special-purpose systolic array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7a: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:Systolic-array-for-matrix-multiplication.gif|thumb|right|250px|Figure 7b: Animation - The systolic product of two 3x3 matrices generated with the help of &amp;lt;ref&amp;gt;http://www.iti.fh-flensburg.de/lang/papers/isa/isa2.htm&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58107</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58107"/>
		<updated>2012-02-06T22:11:07Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Special-purpose systolic array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7a: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7b: Animation - The systolic product of two 3x3 matrices generated with the help of &amp;lt;ref&amp;gt;http://www.iti.fh-flensburg.de/lang/papers/isa/isa2.htm&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic-array-for-matrix-multiplication.gif&amp;diff=58106</id>
		<title>File:Systolic-array-for-matrix-multiplication.gif</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic-array-for-matrix-multiplication.gif&amp;diff=58106"/>
		<updated>2012-02-06T22:09:03Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: Systolic array for matrix multiplication&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Systolic array for matrix multiplication&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58105</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58105"/>
		<updated>2012-02-06T22:08:08Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Special-purpose systolic array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58104</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58104"/>
		<updated>2012-02-06T21:31:44Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Multiple Processors Implementation in Boeing 777http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot;  */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of [http://en.wikipedia.org/wiki/Boeing_777 Boeing 777] were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58103</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58103"/>
		<updated>2012-02-06T21:29:09Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Reconfigurable Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58102</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58102"/>
		<updated>2012-02-06T21:28:19Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Multiple Processors Implementation in Boeing 777http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot;  */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-7 6]]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58101</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58101"/>
		<updated>2012-02-06T21:27:43Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Programmable Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58100</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58100"/>
		<updated>2012-02-06T21:27:26Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Programmable Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58099</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58099"/>
		<updated>2012-02-06T21:25:49Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Programmable Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58098</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58098"/>
		<updated>2012-02-06T21:24:48Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Type of Systolic Arrayshttp://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays  */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-4 5]]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58097</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58097"/>
		<updated>2012-02-06T21:19:21Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Programmable Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Architecture_of_systolic_arrays_as_against_MISD_architecture section 4.1.2.]&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58096</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58096"/>
		<updated>2012-02-06T21:18:32Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Reconfigurable Systolic Array */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the section 4.1.&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Architecture of systolic arrays as against MISD architecture====&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58095</id>
		<title>CSC/ECE 506 Spring 2012/1c dm</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2012/1c_dm&amp;diff=58095"/>
		<updated>2012-02-06T21:17:12Z</updated>

		<summary type="html">&lt;p&gt;Mrshah2: /* Flynn’s Taxonomy of Parallel Computershttp://en.wikipedia.org/wiki/Flynn's_taxonomyhttp://www.phy.ornl.gov/csep/ca/node11.html */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Overview==&lt;br /&gt;
&lt;br /&gt;
This wiki article explores the Multiple Instruction Single Data architecture of multi processors as classified by Flynn’s Taxonomy. The article starts with a description of Flynn’s Taxonomy and its classification followed by the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] and its implementation. It also talks about the authors' and researchers' comments about the real-world examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29MISD architecture] and ends by providing examples of the architecture.&lt;br /&gt;
&lt;br /&gt;
==Multi Processor Systems==&lt;br /&gt;
&lt;br /&gt;
The performance of a single processor system is generally limited by the frequency at which it operates and the amount of [http://en.wikipedia.org/wiki/Instruction-level_parallelism Instruction Level Parallelism (ILP)] it can exploit. The slowdown in the rate of increase in the uni-processor performance arose due to the difficulty in running the processors at higher frequencies and diminishing returns from exploiting ILP. Thus, multiprocessor systems started becoming popular in the applications like servers, graphics intensive tasks, super computers, etc.&lt;br /&gt;
&lt;br /&gt;
A multiprocessor system is the use of two or more processing elements within a single system. Multiple tasks can be executed in parallel on these processing elements depending on the type of the system. The system can have the same kind of processing elements (Homogeneous System) or different kind of processing elements supporting different types of tasks ([http://en.wikipedia.org/wiki/Heterogeneous_computing Heterogeneous System]). &lt;br /&gt;
&lt;br /&gt;
Multiprocessor systems are characterized by the number of instruction streams and the number of data streams the system has. [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Flynn.E2.80.99s_Taxonomy_of_Parallel_Computers.5B1.5D.5B2.5D Flynn’s Taxonomy] gives the characterization of multiprocessor systems.&lt;br /&gt;
&lt;br /&gt;
==Flynn’s Taxonomy of Parallel Computers&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Flynn's_taxonomy&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;http://www.phy.ornl.gov/csep/ca/node11.html&amp;lt;/ref&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
Flynn defined the taxonomy of parallel computers [[http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn], 1972] based on the number of instruction streams and data streams.&lt;br /&gt;
&lt;br /&gt;
•	An Instruction stream is a sequence of instructions followed from a single program counter&lt;br /&gt;
&lt;br /&gt;
•	A Data stream is an address in memory which the instruction operates on.&lt;br /&gt;
&lt;br /&gt;
A control unit fetches instructions from a single program counter, decodes them, and issues them to the processing element.  The processing element is assumed to be a functional unit.  Instruction and data are both supplied from the memory.&lt;br /&gt;
&lt;br /&gt;
The four classifications defined by Flynn are based upon the number of concurrent instruction (or control) and data streams available in the architecture are&amp;lt;ref&amp;gt;https://computing.llnl.gov/tutorials/parallel_comp/#Flynn&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Flynn's Taxonomy.PNG|thumb|center|400px|Figure 1. [http://en.wikipedia.org/wiki/Michael_J._Flynn Flynn]'s Taxonomy [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Single Data stream (SISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SISD.PNG|thumb|right|100px|Figure 2. SISD [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]] &lt;br /&gt;
&lt;br /&gt;
SISD (single instruction, single data) is a term referring to a computer architecture in which a single processor, a uniprocessor, executes a single instruction stream, to operate on data stored in a single memory.  Even though there is only one stream of instructions, parallelism between the instructions from the stream can be exploited when the instructions are independent from one another. This corresponds to the von Neumann architecture. &lt;br /&gt;
&lt;br /&gt;
It is a type of sequential computer which exploits no parallelism in either the instruction or data streams. Single control unit (CU) fetches single Instruction Stream (IS) from memory. The CU then generates appropriate control signals to direct single processing element (PE) to operate on single Data Stream (DS) i.e. one operation at a time&lt;br /&gt;
&lt;br /&gt;
===Single Instruction, Multiple Data streams (SIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:SIMD.PNG|thumb|right|100px|Figure 3. SIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
SIMD is a parallel architecture in which a single instruction operates on multiple data.  An example of SIMD architectures can be found in vector processors.  SIMD is known for its efficiency in terms of the instruction count needed to perform a computation task.&lt;br /&gt;
&lt;br /&gt;
One of the major advantages in SIMD systems is, typically they include only those instructions that can be applied to all of the data in one operation. In other words, if the SIMD system works by loading up eight data points at once, the add operation being applied to the data will happen to all eight values at the same time. Although the same is true for any super-scalar processor design, the level of parallelism in a SIMD system is typically much higher. The major drawback is, it has large register files which increase power consumption and chip area.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instructions, Single Data stream (MISD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MISD.PNG|thumb|right|100px|Figure 4. MISD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MISD (multiple instruction, single data) is an architecture in which multiple processing elements execute from different instruction streams, and data is passed from one processing element to the next.  It is a type of parallel computing architecture where many functional units perform different operations on the same data. &lt;br /&gt;
&lt;br /&gt;
Pipeline architectures belong to this type, though a purist might say that the data is different after processing by each stage in the pipeline. Fault-tolerant computers executing the same instructions redundantly in order to detect and mask errors, in a manner known as task replication, may be considered to belong to this type. Not many instances of this architecture exist, as MIMD and SIMD are often more appropriate for common data parallel techniques. Specifically, they allow better scaling and use of computational resources than MISD does. &lt;br /&gt;
&lt;br /&gt;
However, one prominent example of MISD in computing is the Space Shuttle flight control computers.  Another example of this machine is the systolic array, such as the CMU iWrap [BORKAR et al., 1990].  All the elements in this array are controlled by a global clock. On each cycle, an element will read a piece of data from one of its neighbors, perform a simple operation (e.g. add the incoming element to a stored value), and prepare a value to be written to a neighbor on the next step.&lt;br /&gt;
&lt;br /&gt;
===Multiple Instruction, Multiple Data streams (MIMD)===&lt;br /&gt;
&lt;br /&gt;
[[Image:MIMD.PNG|thumb|right|100px|Figure 5. MIMD Architecture [[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#cite_note-0 1]]]]&lt;br /&gt;
MIMD (multiple instructions, multiple data) is a technique employed to achieve parallelism. Machines using MIMD have a number of processors that function asynchronously and independently. At any time, different processors may be executing different instructions on different pieces of data. MIMD architectures may be used in a number of application areas such as computer-aided design/computer-aided manufacturing, simulation, modeling, and as communication switches. MIMD machines can be of either shared memory or distributed memory categories.  Shared memory machines may be of the bus-based, extended, or hierarchical type. Distributed memory machines may have hypercube or mesh interconnection schemes.&lt;br /&gt;
&lt;br /&gt;
==Implementations of MISD architecture==&lt;br /&gt;
&lt;br /&gt;
===Systolic Array===&lt;br /&gt;
&lt;br /&gt;
A systolic array is an arrangement of processors in an array where data flows synchronously across the array between neighbors, usually with different data flowing in different directions.  Each Processor at each step takes in data from one or more neighbors, processes it and, in the next step, outputs results in the opposite direction.&lt;br /&gt;
&lt;br /&gt;
The systolic array paradigm, data-stream-driven by data counters, is the counterpart of the von Neumann paradigm, instruction-stream-driven by a program counter. Because a systolic array usually sends and receives multiple data streams, and multiple data counters are needed to generate these data streams, it supports data parallelism. The name derives from analogy with the regular pumping of blood by the heart.&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Systolic_array&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Type of Systolic Arrays&amp;lt;ref&amp;gt;http://home.engineering.iastate.edu/~zambreno/classes/cpre583/documents/JohHur93A.pdf General Purpose Systolic Arrays &amp;lt;/ref&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
=====Special-purpose systolic array=====&lt;br /&gt;
[[Image:systolic_1.png|thumb|right|250px|Figure 6: The algorithm for the sum of a scalar product, computed in systolic element]]&lt;br /&gt;
[[Image:systolic_2.png|thumb|right|250px|Figure 7: The systolic product of two 3x3 matrices]]&lt;br /&gt;
&lt;br /&gt;
An array of hardwired systolic processing elements tailored for a specific application.  Typically, many tens or hundreds of cells fit on a single chip. One of the major applications of special-purpose systolic array is in matrix operations.  Figure 6 illustrates the algorithm for the sum of a scalar product, computed in a single systolic element. Here, a’s and b’s are synchronously shifted through the processing element to be available for next element. These data synchronously exits the processing element unmodified for the next element.  The sum of the products is then shifted out of the accumulator.&lt;br /&gt;
&lt;br /&gt;
This principle easily extends to a matrix product as shown in Figure 6. The only difference between single-element processing and array processing is that the latter delays each additional column and row by one cycle so that the columns and rows line up for a matrix multiply. The product matrix is shifted out after completion of processing.&lt;br /&gt;
&lt;br /&gt;
=====General-purpose systolic array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of systolic processing elements, which gets adapted to a variety of applications via programming or reconfiguration.  Array topologies can be either programmable or reconfigurable.  Likewise, array cells are either programmable or reconfigurable.  This is referred to as Systolic topologies.&lt;br /&gt;
&lt;br /&gt;
A programmable systolic architecture is a collection of interconnected, general-purpose systolic cells, each of which is either programmable or reconfigurable.  Programmable systolic cells are flexible processing elements specially designed to meet the computational and I/O requirements of systolic arrays. Programmable systolic architectures can be classified according to their cell inter-connection topologies: fixed or programmable.&lt;br /&gt;
&lt;br /&gt;
Reconfigurable systolic architectures capitalize on FPGA technology, which allows the user to configure a low-level logic circuit for each cell.  Reconfigurable arrays also have either fixed or reconfigurable cell interconnections.  The user configures an array’s topology by means of a switch lattice.  Any general-purpose array that is not conventionally programmable is usually considered reconfigurable.  All FPGA reconfiguring is static due to technology limitations.&lt;br /&gt;
&lt;br /&gt;
Hybrid models make use of both VLSI and FPGA technology.  They usually consist of VLSI circuits embedded in an FPGA-reconfigurable interconnection network.&lt;br /&gt;
&lt;br /&gt;
=====Programmable Systolic Array=====&lt;br /&gt;
&lt;br /&gt;
It is an array of programmable systolic elements that operates either in SIMD or MIMD fashion.  Either the arrays interconnect or each processing unit is programmable and a program controls dataflow through the elements. Programmable systolic arrays are programmable either at a high level or a low level.  At either level, programmable arrays can be categorized as either SIMD or MIMD machines.&lt;br /&gt;
&lt;br /&gt;
* '''SIMD (Single Instruction Multiple Data)'''&lt;br /&gt;
 &lt;br /&gt;
[[Image:systolic_3.png|thumb|right|250px|Figure 8: General organization of SIMD programmable linear systolic arrays]]&lt;br /&gt;
&lt;br /&gt;
In SIMD systolic machines (Figure 8) the host workstation preloads a controller and a memory, which are external to the array, with the instructions and data for the application. The systolic cells store no programs or instructions. As soon as the workstation enables execution, the controller sequences through the external memory thereby delivering instructions and data to the systolic array.  Within the array, instructions are broadcast and all cells perform the same operationon different data. Adjacent cells may share memory, but generally nomemory is shared by theentire array.  After exiting the array, data is collected in the external buffer memory.&lt;br /&gt;
&lt;br /&gt;
This architecture can also be classified based on the number of instruction and data streams as Single Instruction Single Data (SISD) architecture as all the PEs are fed from the same instruction stream and the single data stream passes through all the PEs.&lt;br /&gt;
&lt;br /&gt;
* '''MISD (Multiple Instruction Single Data)'''&lt;br /&gt;
[[Image:systolic_4.png|thumb|right|250px|Figure 9: General organization of MIMD programmable linear systolic arrays]]&lt;br /&gt;
&lt;br /&gt;
The workstation downloads a program to each MISD (Figure 9) systolic cell. Each cell may be loaded with a different program, or all the cells in the array may be loaded with the same program. Each cell's architecture is somewhat similar to the conventional von Neumann architecture: It contains a control unit, an ALU, and local memory. MIMD systolic cells  have  more local  memory  than their  SIMD  counterparts  to  support the  von  Neumann-style  organization.&lt;br /&gt;
&lt;br /&gt;
This architecture is defined as Multiple Instruction Multiple Data (MIMD) architecture in [*Put reference here]. The architecture has multiple instruction streams for the PEs and a single data stream passing through all the PEs. Thus, it can also be defined as Multiple Instruction Single Data (MISD) architecture. The architecture of Systolic array configuration are controversial as explained in the section 4.1.&lt;br /&gt;
&lt;br /&gt;
=====Reconfigurable Systolic Array=====&lt;br /&gt;
[[Image:reconfig.jpg|thumb|right|250px|Figure 10: Block Diagram of the RSA Architecture]]&lt;br /&gt;
It is an array of systolic elements that can be programmed at the lowest level.  Recent gate density advances in FPGA technology have produced a low-level, reconfigurable systolic array architecture that bridges the gap between special-purpose arrays and the more versatile, programmable general-purpose arrays.  The FPGA architecture is unusual because a single hardware platform can be logically reconfigured as an exact duplicate of a special-purpose systolic array. &lt;br /&gt;
&lt;br /&gt;
The RSA circuit design is based on systolic array architecture consisting of PEs interconnected via SWs as depicted in Figure 10. The homogeneous characteristic of the Reconfigurable Systolic Array (RSA) architecture, where each reconfigurable processing element (PE) cell is connected to its nearest neighbors via configurable switch (SW) elements, enables array expansion for parallel processing and facilitates time sharing computation of high-throughput data by individual PEs.  Both the PEs and SWs can be reconfigured dynamically with the former as an arithmetic processor and the latter as a flexible router linking the neighboring PE cells. The RSA shifts reconfiguration and input signals into the PEs and SWs on separate data bus which enables the circuit to continue its operation while the reconfiguration is in process.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Architecture of systolic arrays as against MISD architecture'''&lt;br /&gt;
[[Image:comp.png|thumb|right|250px|Figure 11.Comparison between Architecture of systolic arrays and MISD]]&lt;br /&gt;
&lt;br /&gt;
As from the above mentioned configurations of the Systolic Arrays, it is seen that generally the configurations have multiple processing elements executing different instructions from dedicated instruction streams for each processing element. There is a single data stream that connects the adjacent PEs. Thus, systolic array can be defined as an MISD architecture.&lt;br /&gt;
&lt;br /&gt;
Many authors say that as the data read as input by one processing element is processed data output of the adjacent PE. The data stream cannot be considered as single because all the data paths do not carry the same data to all the PEs. Figure 11 shows the difference between the Data Stream for Systolic Arrays and the MISD architecture. Thus the systolic array should be considered as “Multiple Data” architecture and not Single Data architecture.&lt;br /&gt;
&lt;br /&gt;
===Fault Tolerant Systems&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#Types_of_fault_tolerance&amp;lt;/ref&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
The fault tolerant systems are designed to handle the possible failures in software, hardware or interfaces. The hardware faults include hard disk failures, input or output device failures, etc. and the software and interface faults include  driver failures; operator errors, installing unexpected software etc. The hardware faults can be detected and identified by implementing redundant hardware and multiple backups. The software faults can be tolerable by removing the program errors by executing the software redundantly or by implementing small programs that take over the tasks that crash or generate errors.&lt;br /&gt;
&lt;br /&gt;
====History:&amp;lt;ref&amp;gt;http://en.wikipedia.org/wiki/Fault-tolerant_computer_system#History&amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fault.png|thumb|right|250px|Figure 12 MISD as fault tolerant architecture]]&lt;br /&gt;
The first known fault-tolerant computer was [http://en.wikipedia.org/wiki/SAPO_(computer) SAPO], built in 1951 in [http://en.wikipedia.org/wiki/Czechoslovakia Czechoslovakia] by [http://en.wikipedia.org/wiki/Anton%C3%ADn_Svoboda Antonin Svoboda]. Its basic design was magnetic drums connected via relays, with a voting method of memory error detection.&lt;br /&gt;
&lt;br /&gt;
They separated into three distinct categories: &lt;br /&gt;
* machines that would last a long time without any maintenance&lt;br /&gt;
* computers that were very dependable but required constant monitoring&lt;br /&gt;
* computers with a high amount of runtime which would be under heavy use&lt;br /&gt;
&lt;br /&gt;
Voting was another initial method with multiple redundant backups operating constantly and checking each other's results and reporting the component with non-matching result as faulty. This is called M out of N majority voting.&lt;br /&gt;
&lt;br /&gt;
Historically, motion has always been to move further from N-model and more to M out of N due to the fact that the complexity of systems and the difficulty of ensuring the transitive state from fault-negative to fault-positive did not disrupt operations.&lt;br /&gt;
&lt;br /&gt;
In computer systems, the [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Single_Instruction.2C_Multiple_Data_streams_.28SIMD.29 SIMD], [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD] and [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instruction.2C_Multiple_Data_streams_.28MIMD.29 MIMD] architectures facilitate the implementation of the fault tolerance systems by multiple instruction streams or multiple data streams or both. Fault tolerance on computations can be implemented by multiple processors (likely with different architectures) executing the algorithms on the same set of data. The output of each processor is compared with that of the others and M out of N majority voting method is used to determine the faulty processor. Thus MISD architecture is utilized to get the fault tolerance on critical computations.&lt;br /&gt;
&lt;br /&gt;
There are various examples of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture] being used as fault tolerant architecture. The major examples being flight control systems, nuclear power plants, satellite systems, super collider experiment systems, etc. Here, the flight control system is explained as an example of [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_506_Spring_2012/1c_dm#Multiple_Instructions.2C_Single_Data_stream_.28MISD.29 MISD architecture].&lt;br /&gt;
&lt;br /&gt;
====The Flight Control System – MISD Example for fault tolerance====&lt;br /&gt;
&lt;br /&gt;
A [http://en.wikipedia.org/wiki/Fly-by-wire fly-by-wire] system is used to replace the manual flight control by an electronic control interface. The movements of the flight control in the cockpit are converted to electronic signals and are transmitted to the actuators by wires. The control computers use the feedback from the sensors to compute and control the movement of the actuators to provide the expected response. These computers also perform the task to stabilize the aircraft and perform other tasks without the knowledge of the pilot. Flight control systems must meet extremely high levels of accuracy and functional integrity.&lt;br /&gt;
&lt;br /&gt;
There are redundant flight control computers present in the flight control system. If one of the flight-control computers crashes, gets damaged or is affected by electromagnetic pulses, the other computer can overrule the faulty one and hence the flight of the aircraft is unharmed. The number of redundant flight control computers is generally more than two, so that any computer whose results disagree with the others is ruled out to be faulty and is either ignored or rebooted.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processors Implementation in Boeing 777&amp;lt;ref&amp;gt;http://www.citemaster.net/getdoc/8767/R8.pdf Y.C. (Bob) Yeh, Boeing Commercial Airplane Group, &amp;quot;Triple-Triple Redundant 777 Primary Flight Computer&amp;quot; &amp;lt;/ref&amp;gt;====&lt;br /&gt;
[[Image:fig13.png|thumb|right|250px|Figure 13: Architecture of triple redundant 777 primary flight computer]]&lt;br /&gt;
[[Image:fig14.png|thumb|right|250px|Figure 14: Figure 14: PFC with instruction and data streams]]&lt;br /&gt;
In modern computers, the redundant flight control computations are carried out by multiprocessor systems. The triple redundant 777 primary flight computer, has the architecture as shown in Figure 13.&lt;br /&gt;
&lt;br /&gt;
The system has three primary flight control computers, each of them having three lanes with different processors. The flight control program is compiled for each of the processors which get the input data from the same data bus but drive the output on their individual control bus. Thus each processor executes different instructions but they process the same data. Thus, it is the best suited example of Multiple Instruction Single Data (MISD) architecture.&lt;br /&gt;
&lt;br /&gt;
The three processors selected for the flight control system of Boeing 777 were [http://en.wikipedia.org/wiki/Intel_80486 Intel 80486], [http://en.wikipedia.org/wiki/Motorola_68040 Motorola 68040] and [http://en.wikipedia.org/wiki/AMD_Am29000 AMD 29050]. The dissimilar processors lead to dissimilar interface hardware circuits and compilers. Each lane of the flight control computer is data synchronized with the other lanes so that all of the lanes read the same frame of data from the flight sensors. As the outputs of each lane can be different, the median value of the outputs is used to select the output of the lane to be considered. The lane which has the median value select hardware selected is said to be in “command mode” whereas the other lanes are said to be in “monitoring mode”.  It receives the data from the other Primary Flight Computer (PFC) lanes and performs a median select of the outputs. This provides a fault blocking mechanism before the fault detection and identification by the cross-lane monitoring system. Thus, the MISD based multi computer architecture is capable of detecting generic errors in compilers or in complex hardware devices providing assurance beyond reasonable doubt of the dependability of the Fly-By-Wire system.&lt;br /&gt;
&lt;br /&gt;
The above mentioned system clearly has individual Instruction Streams as the architecture of each processor is different, thus different instruction sets and different instruction streams. These processors have frame synchronized input data which means they have same set of data to work upon which is fed from a single data stream. Thus the flight control system can be classified under MISD architecture.&lt;br /&gt;
&lt;br /&gt;
=='''References'''==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mrshah2</name></author>
	</entry>
</feed>