Distributed shared memory - Revision history

Sennecaster: /* Overview */ cv http://ivizlab.sfu.ca/arya/Papers/IEEE/Concurrency/1996/Summer/Distributed%20Shared%20Memory.htm

2025-05-24T22:23:44Z

Overview: cv http://ivizlab.sfu.ca/arya/Papers/IEEE/Concurrency/1996/Summer/Distributed%20Shared%20Memory.htm

← Previous revision		Revision as of 22:23, 24 May 2025
Line 20:		Line 20:
	== Overview ==		== Overview ==
	[[File:DSM FIGURE.jpg\|330px\|right]]		[[File:DSM FIGURE.jpg\|330px\|right]]

	{{Copyvio\|timestamp=20250207140314 \|url=http://ivizlab.sfu.ca/arya/Papers/IEEE/Concurrency/1996/Summer/Distributed%20Shared%20Memory.htm}}
	A distributed-memory system, often called a [[multicomputer]], consists of multiple independent processing nodes with local memory modules which is connected by a general interconnection network. Software DSM systems can be implemented in an [[operating system]], or as a programming library and can be thought of as extensions of the underlying [[virtual memory]] architecture. When implemented in the operating system, such systems are transparent to the developer; which means that the underlying [[distributed memory]] is completely hidden from the users. In contrast, software DSM systems implemented at the library or language level are not transparent and developers usually have to program them differently. However, these systems offer a more portable approach to DSM system implementations. A DSM system implements the [[shared-memory]] model on a physically distributed memory system.
	</div>

	DSM can be achieved via software as well as hardware. Hardware examples include [[cache coherence]] circuits and [[network interface controller]]s. There are three ways of implementing DSM:		DSM can be achieved via software as well as hardware. Hardware examples include [[cache coherence]] circuits and [[network interface controller]]s. There are three ways of implementing DSM:

MER-C: /* Comparison with message passing */ backwards copy, text was inserted in 2003-2005 source dated 2014

2025-03-07T17:19:39Z

Comparison with message passing: backwards copy, text was inserted in 2003-2005 source dated 2014

← Previous revision		Revision as of 17:19, 7 March 2025
Line 64:		Line 64:
	\| Executing the processes may happen with non-overlapping lifetimes		\| Executing the processes may happen with non-overlapping lifetimes
	\|}		\|}

	{{Copyvio\|timestamp=20250207140314 \|url=https://ijirt.org/publishedpaper/IJIRT101270_PAPER.pdf}}
	Software DSM systems also have the flexibility to organize the shared memory region in different ways. The page based approach organizes shared memory into pages of fixed size. In contrast, the object based approach organizes the shared memory region as an abstract space for storing shareable objects of variable sizes. Another commonly seen implementation uses a [[tuple space]], in which the unit of sharing is a [[tuple]].		Software DSM systems also have the flexibility to organize the shared memory region in different ways. The page based approach organizes shared memory into pages of fixed size. In contrast, the object based approach organizes the shared memory region as an abstract space for storing shareable objects of variable sizes. Another commonly seen implementation uses a [[tuple space]], in which the unit of sharing is a [[tuple]].

	[[Shared memory architecture]] may involve separating memory into shared parts distributed amongst nodes and main memory; or distributing all memory between nodes. A [[coherence protocol]], chosen in accordance with a [[consistency model]], maintains [[memory coherence]].		[[Shared memory architecture]] may involve separating memory into shared parts distributed amongst nodes and main memory; or distributing all memory between nodes. A [[coherence protocol]], chosen in accordance with a [[consistency model]], maintains [[memory coherence]].
	</div>

	==Directory memory coherence==		==Directory memory coherence==

Sophisticatedevening: MOS (via WP:JWB)

2025-02-25T15:02:36Z

MOS (via WP:JWB)

← Previous revision		Revision as of 15:02, 25 February 2025
Line 102:		Line 102:
	The DSM must follow certain rules to maintain consistency over how read and write order is viewed among nodes, called the system's ''[[consistency model]]''.		The DSM must follow certain rules to maintain consistency over how read and write order is viewed among nodes, called the system's ''[[consistency model]]''.

	Suppose we have ''n'' processes and ''Mi'' memory operations for each process ''i'', and that all the operations are executed sequentially. We can conclude that (''M1'' + ''M2'' + … + ''Mn'')!/(''M1''! ''M2''!… ''Mn''!) are possible interleavings of the operations. The issue with this conclusion is determining the correctness of the interleaved operations. Memory coherence for DSM defines which interleavings are permitted.		Suppose we have ''n'' processes and ''Mi'' memory operations for each process ''i'', and that all the operations are executed sequentially. We can conclude that (''M1'' + ''M2'' + ... + ''Mn'')!/(''M1''! ''M2''!... ''Mn''!) are possible interleavings of the operations. The issue with this conclusion is determining the correctness of the interleaved operations. Memory coherence for DSM defines which interleavings are permitted.

	[[File:Sequential invocations and responses in DSM.jpg\|380px\|right\|Sequential invocations and responses in DSM]]		[[File:Sequential invocations and responses in DSM.jpg\|380px\|right\|Sequential invocations and responses in DSM]]

Syn73 at 14:06, 7 February 2025

2025-02-07T14:06:59Z

← Previous revision		Revision as of 14:06, 7 February 2025
Line 1:		Line 1:
			{{Cleanup\|reason=Article is structured like a lecture slide, missing image caption\|date=February 2025}}
	{{Refimprove\|date=January 2022}}		{{Refimprove\|date=January 2022}}
	{{redirect\|DGAS\|the DGA awards\|Directors Guild of America Award}}		{{redirect\|DGAS\|the DGA awards\|Directors Guild of America Award}}

Syn73: copyvio

2025-02-07T14:03:14Z

copyvio

← Previous revision		Revision as of 14:03, 7 February 2025
Line 20:		Line 20:
	[[File:DSM FIGURE.jpg\|330px\|right]]		[[File:DSM FIGURE.jpg\|330px\|right]]

			{{Copyvio\|timestamp=20250207140314 \|url=http://ivizlab.sfu.ca/arya/Papers/IEEE/Concurrency/1996/Summer/Distributed%20Shared%20Memory.htm}}
	A distributed-memory system, often called a [[multicomputer]], consists of multiple independent processing nodes with local memory modules which is connected by a general interconnection network. Software DSM systems can be implemented in an [[operating system]], or as a programming library and can be thought of as extensions of the underlying [[virtual memory]] architecture. When implemented in the operating system, such systems are transparent to the developer; which means that the underlying [[distributed memory]] is completely hidden from the users. In contrast, software DSM systems implemented at the library or language level are not transparent and developers usually have to program them differently. However, these systems offer a more portable approach to DSM system implementations. A DSM system implements the [[shared-memory]] model on a physically distributed memory system.		A distributed-memory system, often called a [[multicomputer]], consists of multiple independent processing nodes with local memory modules which is connected by a general interconnection network. Software DSM systems can be implemented in an [[operating system]], or as a programming library and can be thought of as extensions of the underlying [[virtual memory]] architecture. When implemented in the operating system, such systems are transparent to the developer; which means that the underlying [[distributed memory]] is completely hidden from the users. In contrast, software DSM systems implemented at the library or language level are not transparent and developers usually have to program them differently. However, these systems offer a more portable approach to DSM system implementations. A DSM system implements the [[shared-memory]] model on a physically distributed memory system.
			</div>

	DSM can be achieved via software as well as hardware. Hardware examples include [[cache coherence]] circuits and [[network interface controller]]s. There are three ways of implementing DSM:		DSM can be achieved via software as well as hardware. Hardware examples include [[cache coherence]] circuits and [[network interface controller]]s. There are three ways of implementing DSM:
Line 61:		Line 63:
	\| Executing the processes may happen with non-overlapping lifetimes		\| Executing the processes may happen with non-overlapping lifetimes
	\|}		\|}
			{{Copyvio\|timestamp=20250207140314 \|url=https://ijirt.org/publishedpaper/IJIRT101270_PAPER.pdf}}

	Software DSM systems also have the flexibility to organize the shared memory region in different ways. The page based approach organizes shared memory into pages of fixed size. In contrast, the object based approach organizes the shared memory region as an abstract space for storing shareable objects of variable sizes. Another commonly seen implementation uses a [[tuple space]], in which the unit of sharing is a [[tuple]].		Software DSM systems also have the flexibility to organize the shared memory region in different ways. The page based approach organizes shared memory into pages of fixed size. In contrast, the object based approach organizes the shared memory region as an abstract space for storing shareable objects of variable sizes. Another commonly seen implementation uses a [[tuple space]], in which the unit of sharing is a [[tuple]].

	[[Shared memory architecture]] may involve separating memory into shared parts distributed amongst nodes and main memory; or distributing all memory between nodes. A [[coherence protocol]], chosen in accordance with a [[consistency model]], maintains [[memory coherence]].		[[Shared memory architecture]] may involve separating memory into shared parts distributed amongst nodes and main memory; or distributing all memory between nodes. A [[coherence protocol]], chosen in accordance with a [[consistency model]], maintains [[memory coherence]].
			</div>

	==Directory memory coherence==		==Directory memory coherence==

Mewtow: /* Directory memory coherence */

2024-10-02T13:42:17Z

Directory memory coherence

← Previous revision		Revision as of 13:42, 2 October 2024
Line 67:		Line 67:

	==Directory memory coherence==		==Directory memory coherence==
			{{main\|Directory-based cache coherence}}
	[[Memory coherence]] is necessary such that the system which organizes the DSM is able to track and maintain the state of data blocks in nodes across the memories comprising the system. A directory is one such mechanism which maintains the state of cache blocks moving around the system.		[[Memory coherence]] is necessary such that the system which organizes the DSM is able to track and maintain the state of data blocks in nodes across the memories comprising the system. A directory is one such mechanism which maintains the state of cache blocks moving around the system.

InternetArchiveBot: Rescuing 2 sources and tagging 0 as dead.) #IABot (v2.0.9.5

2024-02-04T05:46:43Z

Rescuing 2 sources and tagging 0 as dead.) #IABot (v2.0.9.5

← Previous revision		Revision as of 05:46, 4 February 2024
Line 115:		Line 115:
	* Release consistency: when a process exits a [[critical section]], new values of the variables are propagated to all sites.		* Release consistency: when a process exits a [[critical section]], new values of the variables are propagated to all sites.
	* Entry consistency: when a process enters a critical section, it will automatically update the values of the shared variables.		* Entry consistency: when a process enters a critical section, it will automatically update the values of the shared variables.
	** View-based Consistency: it is a variant of Entry Consistency, except the shared variables of a critical section are automatically detected by the system. An implementation of view-based consistency is [http://vodca.otago.ac.nz VODCA] which has comparable performance to [[Message Passing Interface\|MPI]] on cluster computers.		** View-based Consistency: it is a variant of Entry Consistency, except the shared variables of a critical section are automatically detected by the system. An implementation of view-based consistency is [http://vodca.otago.ac.nz VODCA] {{Webarchive\|url=https://web.archive.org/web/20160215102157/http://vodca.otago.ac.nz/ \|date=2016-02-15 }} which has comparable performance to [[Message Passing Interface\|MPI]] on cluster computers.

	=== Examples ===		=== Examples ===
Line 122:		Line 122:
	* [[MOSIX]]		* [[MOSIX]]
	* [[TreadMarks]]		* [[TreadMarks]]
	* [http://vodca.otago.ac.nz VODCA]		* [http://vodca.otago.ac.nz VODCA] {{Webarchive\|url=https://web.archive.org/web/20160215102157/http://vodca.otago.ac.nz/ \|date=2016-02-15 }}
	* [http://dipc-2.sourceforge.net/ DIPC]		* [http://dipc-2.sourceforge.net/ DIPC]

Citation bot: Alter: pages. Formatted dashes. | Use this bot. Report bugs. | Suggested by Whoop whoop pull up | #UCB_webform 35/134

2023-03-29T16:39:11Z

Alter: pages. Formatted dashes. | Use this bot. Report bugs. | Suggested by Whoop whoop pull up | #UCB_webform 35/134

← Previous revision		Revision as of 16:39, 29 March 2023
Line 72:		Line 72:
	[[File:Dsm states.png\|right\|280px\|State diagram of a block of memory in a DSM. A block is "owned" if one of the nodes has the block in state EM.]]		[[File:Dsm states.png\|right\|280px\|State diagram of a block of memory in a DSM. A block is "owned" if one of the nodes has the block in state EM.]]

	A basic DSM will track at least three states among nodes for any given block in the directory.<ref>{{Cite book\|title=Fundamentals of Parallel Multicore Architecture\|last=Solihin\|first=Yan\|publisher=Chapman and Hall/CRC\|year=2015\|isbn=9781482211184\|location=Boca Raton, Florida\|pages=~~339-340~~}}</ref> There will be some state to dictate the block as uncached (U), a state to dictate a block as exclusively owned or modified owned (EM), and a state to dictate a block as shared (S). As blocks come into the directory organization, they will transition from U to EM (ownership state) in the initial node. The state can transition to S when other nodes begin reading the block.		A basic DSM will track at least three states among nodes for any given block in the directory.<ref>{{Cite book\|title=Fundamentals of Parallel Multicore Architecture\|last=Solihin\|first=Yan\|publisher=Chapman and Hall/CRC\|year=2015\|isbn=9781482211184\|location=Boca Raton, Florida\|pages=339–340}}</ref> There will be some state to dictate the block as uncached (U), a state to dictate a block as exclusively owned or modified owned (EM), and a state to dictate a block as shared (S). As blocks come into the directory organization, they will transition from U to EM (ownership state) in the initial node. The state can transition to S when other nodes begin reading the block.

	There are two primary methods for allowing the system to track where blocks are cached and in what condition across each node. Home-centric request-response uses the home to service requests and drive states, whereas requester-centric allows each node to drive and manage its own requests through the home.		There are two primary methods for allowing the system to track where blocks are cached and in what condition across each node. Home-centric request-response uses the home to service requests and drive states, whereas requester-centric allows each node to drive and manage its own requests through the home.

Corundumconundrum: /* Disadvantages */ erroneous comma

2023-03-02T08:12:53Z

Disadvantages: erroneous comma

← Previous revision		Revision as of 08:12, 2 March 2023
Line 41:		Line 41:
	* May incur a performance penalty		* May incur a performance penalty
	* Little programmer control over actual messages being generated		* Little programmer control over actual messages being generated
	* Programmers need to understand consistency models, to write correct programs		* Programmers need to understand consistency models to write correct programs

	===Comparison with message passing ===		===Comparison with message passing ===

A3232648: Added a relevant "See also"

2023-02-07T19:24:40Z

Added a relevant "See also"

← Previous revision		Revision as of 19:24, 7 February 2023
Line 129:		Line 129:
	* {{annotated link\|Memory virtualization}}		* {{annotated link\|Memory virtualization}}
	* {{annotated link\|Single-system image}}		* {{annotated link\|Single-system image}}
			* {{annotated link\|Remote direct memory access}}

	==References==		==References==

← Previous revision		Revision as of 14:06, 7 February 2025
Line 1:		Line 1:
			{{Cleanup\|reason=Article is structured like a lecture slide, missing image caption\|date=February 2025}}
	{{Refimprove\|date=January 2022}}		{{Refimprove\|date=January 2022}}
	{{redirect\|DGAS\|the DGA awards\|Directors Guild of America Award}}		{{redirect\|DGAS\|the DGA awards\|Directors Guild of America Award}}