Admin: cont

Admin — Sun, 06 Mar 2011 05:47:03 GMT

cont

← Older revision		Revision as of 05:47, 6 March 2011
Line 1:		Line 1:
	Shared memory is a memory-area, which is able to access from more as one process. It is a possibility given in some platforms. A process in this meaning is a portion of software maybe with more as one thread, which is running on the same platform simultaneously with other processes. But the processes are separated in the usage of the resources. Especially they haven't a common memory. It is to protect the processes against failures in the software.		Shared memory is a memory-area, which is able to access from more as one process. It is a possibility given in some platforms. A process in this meaning is a portion of software maybe with more as one thread, which is running on the same platform simultaneously with other processes. But the processes are separated in the usage of the resources. Especially they haven't a common memory. It is to protect the processes against failures in the software.

-	The shared memory is not a mechanism, which is able to use on any platform. Therefore it is not a part of the common OSAL interface definition.	+	'''The shared memory is not a mechanism, which is able to use on any platform'''. Therefore it is not a part of the common OSAL interface definition.
		+
		+	'''Use InterProcessComm as means of expression instead''':

	If shared memory is used, it is a problem of the communication between processes. Therefore the mechanism of [[InterProcessCommunication]] should be used instead:		If shared memory is used, it is a problem of the communication between processes. Therefore the mechanism of [[InterProcessCommunication]] should be used instead:

	* <tt>InterProcessComm.open(ChannelSpec);</tt> to open a communication channel. It may create a shared-memory-access-object.		* <tt>InterProcessComm.open(ChannelSpec);</tt> to open a communication channel. It may create a shared-memory-access-object.
-	* <tt>InterProcessComm.receive(...);</tt>: Receive any data from another process. It may check the shared memory whether expected information are given. It is not specified which addresses and which information inside the shared memory are checked. The receive operation is a broadcast-receive. To specify a finer granularity in information-receiving, there should be more as one <tt>open(...)</tt>-operations which are associated to parts of information in the shared memory. The <tt>receive(...)</tt>-operation is more ''wait for event''-adequate as ''read memory''. But usual it is it, which are expected in a communication between processes. The user should rather think about ''I will use the shared memory'' but ''I have to get events from another process''.	+	* <tt>InterProcessComm.receive(...);</tt>: Receive any data from another process. It may check the shared memory whether expected information are given. It is not specified which addresses and which information inside the shared memory are checked. The receive operation is a broadcast-receive. To specify a finer granularity in information-receiving, there should be more as one <tt>open(...)</tt>-operations which are associated to parts of information in the shared memory. The <tt>receive(...)</tt>-operation is more ''wait for event''-adequate as ''read memory''. But usual it is it, which are expected in a communication between processes. The user should rather think about ''I will use the shared memory'' but ''I have to get events from another process''. If receive is used for shared memory, the <tt>receive(..., sender)</tt>-method can look to control bits in more as one ranges in shared memory. It can return several data specifying the source of the data in the <tt>sender</tt>.
		+
		+	* <tt>InterProcessComm.send(data, address);</tt>: it sets informations, maybe setting values in the shared memory. The address can be select which range, the data are the byte-data for the range. It is equal to send an information to a specified channel.
		+
		+	* The methods <tt>InterProcessComm.capacityToSendWithoutBlocking(requestedNumber)</tt> and <tt>dataAvailable()</tt> can be used to poll the data situation.

-	* <tt>InterProcessComm.send(data, ~~address);</tt>:~~ it ~~sets informations~~, ~~maybe setting values in the shared memory~~	+	If specific data struct are used inside a shared memory, it should be recognized as a problem of a driver level, not as part of a user program.

Admin: Protected "Os Shared Memory" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

Admin — Sun, 06 Mar 2011 05:37:34 GMT

Protected "Os Shared Memory" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

← Older revision

Revision as of 05:37, 6 March 2011

Admin: first

Admin — Sat, 05 Mar 2011 21:22:30 GMT

first

New page

Shared memory is a memory-area, which is able to access from more as one process. It is a possibility given in some platforms. A process in this meaning is a portion of software maybe with more as one thread, which is running on the same platform simultaneously with other processes. But the processes are separated in the usage of the resources. Especially they haven't a common memory. It is to protect the processes against failures in the software.

The shared memory is not a mechanism, which is able to use on any platform. Therefore it is not a part of the common OSAL interface definition.

If shared memory is used, it is a problem of the communication between processes. Therefore the mechanism of [[InterProcessCommunication]] should be used instead:

* <tt>InterProcessComm.open(ChannelSpec);</tt> to open a communication channel. It may create a shared-memory-access-object.
* <tt>InterProcessComm.receive(...);</tt>: Receive any data from another process. It may check the shared memory whether expected information are given. It is not specified which addresses and which information inside the shared memory are checked. The receive operation is a broadcast-receive. To specify a finer granularity in information-receiving, there should be more as one <tt>open(...)</tt>-operations which are associated to parts of information in the shared memory. The <tt>receive(...)</tt>-operation is more ''wait for event''-adequate as ''read memory''. But usual it is it, which are expected in a communication between processes. The user should rather think about ''I will use the shared memory'' but ''I have to get events from another process''.

* <tt>InterProcessComm.send(data, address);</tt>: it sets informations, maybe setting values in the shared memory

Os Shared Memory - Revision history

Admin: cont

Admin: Protected "Os Shared Memory" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

Admin: first