Welcome
» The NERW Reference Model
While the first essence of concurrent computing is the existence of multiple processing elements (or pels), the second essence is for these pels to exchange information in order to achieve some common goal set by the application. The state-of-the-art has an abundance of methods to support the sharing of this information between execution entities. We have shared memories, message passing, rendez-vous, ports, portals, pipes, tuples, channels, extends, distributed objects, locks-and-monitors, transactional memory and more. The NERW reference model abstracts all these methods into a basic concept, the memory element or mel.
The presence of the term "memory" in the mel name does not mean that the NERW model requires physical "shared memory". Shared memory is just one way to implement shared information. Another way is to locally cache the shared information and broadcast updates for everybody to synchronize. Yet another way is to centralize the shared information into a server and have clients send messages to request access. And there are many other ways to pass around shared information, as identified in the previous paragraph.
While the mel represents the logical aspect of shared information, this information must physically reside somewhere. The physical locale is provided by the NERW element cel. Like the pel, a NERW programmer usually does not need to know where a mel resides -- the CHAOS runtime will take care of this task behind the scene. In cases the programmer needs to know, the NERW reference model allows a programmer to specifically assign a cel locale to a mel. A cel may represent a huge hard drive, a fast solid-state drive, a faster RAM disk, or special video memory; and shared mel data can be assigned to these cels for special-purposed processing.
A cel can support a single mel or multiple mels, depending on the hardware support. A cel can be specialized to support only mels, or can be generic to host both pels and mels. For example, a personal computer (PC) can be viewed as a cel that has both pels (CPU and thread-supporting OS) and mels (RAM and hard drives).
An implementation of the CHAOS runtime can support different types of mels. For example, a system may support physical shared memory for local processes, and communicating channels for networked processes. At the conceptual level, they are the same: they facilitate shared information, of which the NERW Concurrency Model abstracts as mels.
Mel Implementations
See Mel in NERWous C.
Previous Next Top
While the first essence of concurrent computing is the existence of multiple processing elements (or pels), the second essence is for these pels to exchange information in order to achieve some common goal set by the application. The state-of-the-art has an abundance of methods to support the sharing of this information between execution entities. We have shared memories, message passing, rendez-vous, ports, portals, pipes, tuples, channels, extends, distributed objects, locks-and-monitors, transactional memory and more. The NERW reference model abstracts all these methods into a basic concept, the memory element or mel.
The presence of the term "memory" in the mel name does not mean that the NERW model requires physical "shared memory". Shared memory is just one way to implement shared information. Another way is to locally cache the shared information and broadcast updates for everybody to synchronize. Yet another way is to centralize the shared information into a server and have clients send messages to request access. And there are many other ways to pass around shared information, as identified in the previous paragraph.
While the mel represents the logical aspect of shared information, this information must physically reside somewhere. The physical locale is provided by the NERW element cel. Like the pel, a NERW programmer usually does not need to know where a mel resides -- the CHAOS runtime will take care of this task behind the scene. In cases the programmer needs to know, the NERW reference model allows a programmer to specifically assign a cel locale to a mel. A cel may represent a huge hard drive, a fast solid-state drive, a faster RAM disk, or special video memory; and shared mel data can be assigned to these cels for special-purposed processing.
A cel can support a single mel or multiple mels, depending on the hardware support. A cel can be specialized to support only mels, or can be generic to host both pels and mels. For example, a personal computer (PC) can be viewed as a cel that has both pels (CPU and thread-supporting OS) and mels (RAM and hard drives).
An implementation of the CHAOS runtime can support different types of mels. For example, a system may support physical shared memory for local processes, and communicating channels for networked processes. At the conceptual level, they are the same: they facilitate shared information, of which the NERW Concurrency Model abstracts as mels.
Mel Implementations
See Mel in NERWous C.
Previous Next Top
No comments:
Post a Comment