CSC/ECE 506 Spring 2012/8b va - Revision history

Mavasqu2: /* Write-Invalidate Protocol */

2012-04-03T00:45:48Z

Write-Invalidate Protocol

← Older revision		Revision as of 00:45, 3 April 2012
Line 29:		Line 29:
	<dl>		<dl>
	<dd>Under the invalidation scheme, updates are only propagated when data are read, and several updates can take place before communication is necessary. Against this must be placed the cost of invalidating read-only copies before a write can occur. In the multiple-reader-single-write scheme described, this is potentially expensive. But, if the read/write ratio is sufficiently high, then the parallelism obtained by allowing multiple simultaneous readers offsets this cost. Where the read/write ratio is relatively small, a single-reader-single-writer scheme can be more appropriate: i.e, one in which at most one process may be granted read-only access at a time.		<dd>Under the invalidation scheme, updates are only propagated when data are read, and several updates can take place before communication is necessary. Against this must be placed the cost of invalidating read-only copies before a write can occur. In the multiple-reader-single-write scheme described, this is potentially expensive. But, if the read/write ratio is sufficiently high, then the parallelism obtained by allowing multiple simultaneous readers offsets this cost. Where the read/write ratio is relatively small, a single-reader-single-writer scheme can be more appropriate: i.e, one in which at most one process may be granted read-only access at a time.
	<dd> ~~In this~~ article ~~we focus~~ on the write-update protocol ~~and not so much on~~ the write-invalidate protocol. If the reader wants to seek more information regarding this protocol, please go to [http://cs.gmu.edu/cne/modules/dsm/green/coherence.html this page] as it will provide insightful and meaning description and demonstration on how this protocol operates.		<dd> This article focuses on the write-update protocol leaving the reader to investigate write-invalidate protocol through own research. If the reader wants to seek more information regarding this protocol, please go to [http://cs.gmu.edu/cne/modules/dsm/green/coherence.html this page] as it will provide insightful and meaning description and demonstration on how this protocol operates.
	</dl>		</dl>

Mavasqu2: /* Write-Invalidate Protocol */

2012-04-03T00:39:46Z

Write-Invalidate Protocol

← Older revision		Revision as of 00:39, 3 April 2012
Line 29:		Line 29:
	<dl>		<dl>
	<dd>Under the invalidation scheme, updates are only propagated when data are read, and several updates can take place before communication is necessary. Against this must be placed the cost of invalidating read-only copies before a write can occur. In the multiple-reader-single-write scheme described, this is potentially expensive. But, if the read/write ratio is sufficiently high, then the parallelism obtained by allowing multiple simultaneous readers offsets this cost. Where the read/write ratio is relatively small, a single-reader-single-writer scheme can be more appropriate: i.e, one in which at most one process may be granted read-only access at a time.		<dd>Under the invalidation scheme, updates are only propagated when data are read, and several updates can take place before communication is necessary. Against this must be placed the cost of invalidating read-only copies before a write can occur. In the multiple-reader-single-write scheme described, this is potentially expensive. But, if the read/write ratio is sufficiently high, then the parallelism obtained by allowing multiple simultaneous readers offsets this cost. Where the read/write ratio is relatively small, a single-reader-single-writer scheme can be more appropriate: i.e, one in which at most one process may be granted read-only access at a time.
	<dd> In this article we focus on the write-update protocol and not so much on the write-invalidate protocol. If the reader ~~what~~ to seek more information regarding this protocol, please go to [http://cs.gmu.edu/cne/modules/dsm/green/coherence.html this page] as it will provide insightful and meaning description and demonstration on how this protocol operates.		<dd> In this article we focus on the write-update protocol and not so much on the write-invalidate protocol. If the reader wants to seek more information regarding this protocol, please go to [http://cs.gmu.edu/cne/modules/dsm/green/coherence.html this page] as it will provide insightful and meaning description and demonstration on how this protocol operates.
	</dl>		</dl>

Mavasqu2: /* Write-Invalidate Protocol */

2012-04-03T00:37:31Z

Write-Invalidate Protocol

← Older revision		Revision as of 00:37, 3 April 2012
Line 29:		Line 29:
	<dl>		<dl>
	<dd>Under the invalidation scheme, updates are only propagated when data are read, and several updates can take place before communication is necessary. Against this must be placed the cost of invalidating read-only copies before a write can occur. In the multiple-reader-single-write scheme described, this is potentially expensive. But, if the read/write ratio is sufficiently high, then the parallelism obtained by allowing multiple simultaneous readers offsets this cost. Where the read/write ratio is relatively small, a single-reader-single-writer scheme can be more appropriate: i.e, one in which at most one process may be granted read-only access at a time.		<dd>Under the invalidation scheme, updates are only propagated when data are read, and several updates can take place before communication is necessary. Against this must be placed the cost of invalidating read-only copies before a write can occur. In the multiple-reader-single-write scheme described, this is potentially expensive. But, if the read/write ratio is sufficiently high, then the parallelism obtained by allowing multiple simultaneous readers offsets this cost. Where the read/write ratio is relatively small, a single-reader-single-writer scheme can be more appropriate: i.e, one in which at most one process may be granted read-only access at a time.
	<dd> In this article we focus on the write-update protocol and not so much on the write-invalidate protocol. If the reader what to seek more information regarding this protocol, please go to this page as it will provide insightful and meaning description and demonstration on how this protocol operates.		<dd> In this article we focus on the write-update protocol and not so much on the write-invalidate protocol. If the reader what to seek more information regarding this protocol, please go to [http://cs.gmu.edu/cne/modules/dsm/green/coherence.html this page] as it will provide insightful and meaning description and demonstration on how this protocol operates.
	</dl>		</dl>

	~~http://cs.gmu.edu/cne/modules/dsm/green/coherence.html~~


	=Write-Update Protocol=		=Write-Update Protocol=

Mavasqu2: /* Write-Update Protocol */

2012-04-03T00:35:39Z

Write-Update Protocol

← Older revision		Revision as of 00:35, 3 April 2012
Line 25:		Line 25:
	'''Write-Invalidate Protocol'''		'''Write-Invalidate Protocol'''
	In a [http://cs.gmu.edu/cne/modules/dsm/purple/wr_inval.html Write-Invalidate Protocol] a processor invalidates all other processors cache block and then updates its own cache block without further bus operations.		In a [http://cs.gmu.edu/cne/modules/dsm/purple/wr_inval.html Write-Invalidate Protocol] a processor invalidates all other processors cache block and then updates its own cache block without further bus operations.

			=Write-Invalidate Protocol=
			<dl>
			<dd>Under the invalidation scheme, updates are only propagated when data are read, and several updates can take place before communication is necessary. Against this must be placed the cost of invalidating read-only copies before a write can occur. In the multiple-reader-single-write scheme described, this is potentially expensive. But, if the read/write ratio is sufficiently high, then the parallelism obtained by allowing multiple simultaneous readers offsets this cost. Where the read/write ratio is relatively small, a single-reader-single-writer scheme can be more appropriate: i.e, one in which at most one process may be granted read-only access at a time.
			<dd> In this article we focus on the write-update protocol and not so much on the write-invalidate protocol. If the reader what to seek more information regarding this protocol, please go to this page as it will provide insightful and meaning description and demonstration on how this protocol operates.
			</dl>

			http://cs.gmu.edu/cne/modules/dsm/green/coherence.html


	=Write-Update Protocol=		=Write-Update Protocol=

	Interchangeably,in a [http://cs.gmu.edu/cne/modules/dsm/purple/wr_update.html Write-Uptade Protocol], a processor broadcasts updates to shared data to other caches so other cashes stay coherent.		Interchangeably,in a [http://cs.gmu.edu/cne/modules/dsm/purple/wr_update.html Write-Uptade Protocol], a processor broadcasts updates to shared data to other caches so other cashes stay coherent.
	<ref>[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCIQFjAA&url=ftp%3A%2F%2Fftp.cs.washington.edu%2Ftr%2F1994%2F05%2FUW-CSE-94-05-02.PS.Z&ei=2n9kT8gjhPDSAaO2nb4P&usg=AFQjCNFFRgsJiBWjKAMOHcGcRL_vkkSqLg&sig2=aYWddXJdXsNNIFQ5U4zoqg Two techniques for improving performance on bus-based mu1tiprocessors]</ref>		<ref>[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCIQFjAA&url=ftp%3A%2F%2Fftp.cs.washington.edu%2Ftr%2F1994%2F05%2FUW-CSE-94-05-02.PS.Z&ei=2n9kT8gjhPDSAaO2nb4P&usg=AFQjCNFFRgsJiBWjKAMOHcGcRL_vkkSqLg&sig2=aYWddXJdXsNNIFQ5U4zoqg Two techniques for improving performance on bus-based mu1tiprocessors]</ref>

Mavasqu2: /* Dragon Protocol */

2012-04-03T00:24:16Z

Dragon Protocol

← Older revision		Revision as of 00:24, 3 April 2012
Line 38:		Line 38:

	===Dragon Protocol===		===Dragon Protocol===
	[[File:Screen_Shot_2012-03-~~28_at_10~~.29.~~04_PM~~.png\|thumb\|upright=10.5\|right\|alt=A large clock tower and other buildings line a great river.\|Table 1: Definitions of additional notations in the state transition diagram of Dragon Protocol]]		[[File:Screen_Shot_2012-04-02_at_8.21.48_PM.png\|thumb\|upright=2.5\|right\|alt=A large clock tower and other buildings line a great river.\|Table 1: Definitions of additional notations in the state transition diagram of Dragon Protocol]]
	[[File:Screen Shot 2012-03-28 at 10.18.57 PM.png\|thumb\|upright=2.5\|right\|alt=A large clock tower and other buildings line a great river.\|Figure 2 depicts the state transition diagram of the Dragon protocol]]		[[File:Screen Shot 2012-03-28 at 10.18.57 PM.png\|thumb\|upright=2.5\|right\|alt=A large clock tower and other buildings line a great river.\|Figure 2 depicts the state transition diagram of the Dragon protocol]]
	<dd>This protocol was first proposed by researchers at Xerox PARC for their Dragon multiprocessor system.		<dd>This protocol was first proposed by researchers at Xerox PARC for their Dragon multiprocessor system.

Sbasu3: /* Dragon Protocol */

2012-03-29T04:28:30Z

Dragon Protocol

← Older revision		Revision as of 04:28, 29 March 2012
Line 53:		Line 53:


	[http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.29.~~04_PM~~.png Figure 2] depicts the state transition diagram of the Dragon protocol, and [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.29.04_PM.png Table 1] details the additional notations in the state transition diagram.		[http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.18.57_PM.png Figure 2] depicts the state transition diagram of the Dragon protocol, and [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.29.04_PM.png Table 1] details the additional notations in the state transition diagram.

	===Firefly Protocol===		===Firefly Protocol===

Sbasu3: /* Dragon Protocol */

2012-03-29T04:27:25Z

Dragon Protocol

← Older revision		Revision as of 04:27, 29 March 2012
Line 53:		Line 53:


	depicts the state transition diagram of the ~~Firefly~~ protocol, and [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-~~29_at_12~~.14.~~24_AM~~.png Table 2] details the additional notations in the state transition diagram.		[http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.29.04_PM.png Figure 2] depicts the state transition diagram of the Dragon protocol, and [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.29.04_PM.png Table 1] details the additional notations in the state transition diagram.

	===Firefly Protocol===		===Firefly Protocol===

Sbasu3: /* Dragon Protocol */

2012-03-29T04:24:55Z

Dragon Protocol

← Older revision		Revision as of 04:24, 29 March 2012
Line 53:		Line 53:


			depicts the state transition diagram of the Firefly protocol, and [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-29_at_12.14.24_AM.png Table 2] details the additional notations in the state transition diagram.









	===Firefly Protocol===		===Firefly Protocol===

Sbasu3: /* Firefly Protocol */

2012-03-29T04:23:38Z

Firefly Protocol

← Older revision		Revision as of 04:23, 29 March 2012
Line 71:		Line 71:
	<dd>'''Valid (V): '''This block has a coherent copy of the memory. There is only one copy of the data in caches.		<dd>'''Valid (V): '''This block has a coherent copy of the memory. There is only one copy of the data in caches.
	<dd>'''Dirty (D):''' The block is the only copy of the memory and it is incoherent. This is the only state that generates a write-back when the block is replaced in the cache.		<dd>'''Dirty (D):''' The block is the only copy of the memory and it is incoherent. This is the only state that generates a write-back when the block is replaced in the cache.
	<dd>'''Shared (S):''' This block has a coherent copy of the memory. The data may be possibly shared, but its content is not modified. [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.19.25_PM.png Figure 3] depicts the state transition diagram of the Firefly protocol, and Table 1 details the additional notations in the state transition diagram.		<dd>'''Shared (S):''' This block has a coherent copy of the memory. The data may be possibly shared, but its content is not modified.

			[http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.19.25_PM.png Figure 3] depicts the state transition diagram of the Firefly protocol, and [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-29_at_12.14.24_AM.png Table 2] details the additional notations in the state transition diagram.
	[[File:Screen_Shot_2012-03-28_at_10.19.25_PM.png\|thumb\|upright=2.5\|center\|alt=A large clock tower and other buildings line a great river.\|Figure 3: State diagram of the Firefly protocol.]]		[[File:Screen_Shot_2012-03-28_at_10.19.25_PM.png\|thumb\|upright=2.5\|center\|alt=A large clock tower and other buildings line a great river.\|Figure 3: State diagram of the Firefly protocol.]]

Sbasu3: /* Firefly Protocol */

2012-03-29T04:21:36Z

Firefly Protocol

← Older revision		Revision as of 04:21, 29 March 2012
Line 71:		Line 71:
	<dd>'''Valid (V): '''This block has a coherent copy of the memory. There is only one copy of the data in caches.		<dd>'''Valid (V): '''This block has a coherent copy of the memory. There is only one copy of the data in caches.
	<dd>'''Dirty (D):''' The block is the only copy of the memory and it is incoherent. This is the only state that generates a write-back when the block is replaced in the cache.		<dd>'''Dirty (D):''' The block is the only copy of the memory and it is incoherent. This is the only state that generates a write-back when the block is replaced in the cache.
	<dd>'''Shared (S):''' This block has a coherent copy of the memory. The data may be possibly shared, but its content is not modified. Figure 3 depicts the state transition diagram of the Firefly protocol, and Table 1 details the additional notations in the state transition diagram.		<dd>'''Shared (S):''' This block has a coherent copy of the memory. The data may be possibly shared, but its content is not modified. [http://expertiza.csc.ncsu.edu/wiki/index.php/File:Screen_Shot_2012-03-28_at_10.19.25_PM.png Figure 3] depicts the state transition diagram of the Firefly protocol, and Table 1 details the additional notations in the state transition diagram.
	[[File:Screen_Shot_2012-03-28_at_10.19.25_PM.png\|thumb\|upright=2.5\|center\|alt=A large clock tower and other buildings line a great river.\|Figure 3: State diagram of the Firefly protocol.]]		[[File:Screen_Shot_2012-03-28_at_10.19.25_PM.png\|thumb\|upright=2.5\|center\|alt=A large clock tower and other buildings line a great river.\|Figure 3: State diagram of the Firefly protocol.]]