Mel Location

Welcome » NERWous C » Mel

1. At Attribute
2. At Values
3. DOWN Exception
4. Examples

---

At Attribute

As introduced, the mel variable is an abstract element that stores values. To store a physical entity, the mel must have a physical location somewhere. In general, applications do not care about this somewhere. Then there are cases where the application must know where this location is. In NERWous C, this capability is supported by the at attribute of the mel command:

extern <cel> NODE;
main () {
     <mel at=NODE> int store;
     <!> Producer (store);
     <!> Consumer (store);
}
void Producer (<mel> int store) {
     int c;
     while ( c = Produce() )
         <?>store = c;

     <close>store;
}
void Consumer (<mel> int store) {
    try {
         while ( 1 )
             Consume(<?>store);
     } catch ( store<CLOSED> ) {
         return;
     }
}

The cel NODE is defined as an extern. Its definition will come from a configuration file that is associated with the above NERWous C program. This configuration file is specific to the runtime environment, and allows the same NERWous C program to be run on different physical platforms.

If the above program runs a distributed process over the web then the NODE value will contain the address of a web page. The read and write operations to the mel translate to sending a request to the web page and waiting for the result. The code behind the web page will implement the mel characteristics such as mutual exclusion, priorities and timeouts. The real storage for the mel is also behind the web site, and can be a persistent memory, a file or even a record in a database. All this is transparent to the Producer / Consumer program.

To run in a distributed web environment, besides the configuration file, the code must be compiled with a NERWous C library for web transactions. To run the same code in another environment (such as a closely-coupled shared-memory supercomputer), the above code has to be recompiled with the appropriate library.

---

At Value

The value of the at attribute is either a computer element (cel) variable or the identification value of the computer element. For example:

#define NODEURL "https://melstore.nerw/"

<cel>storeloc;
storeloc<id> = NODEURL;
<mel at=storeloc> int store1;

<mel at=NODEURL> int store2;

In the first use, the cel variable storeloc is initialized with the NODEURL id (which is a web address in this example), and used as the location of the mel store1. In the second use, the mel variable store2 specifies the NODEURL id directly, and thus resides in the same location as store1.

When an id value is used, a stand-in cel entity is automatically created by the at attribute. This cel can be later accessed via the mel property location:

<mel at=NODEURL> int store2;
cel storeloc2 = store2<location>;
printf ("The id of storeloc2 (%s) is the same as (%s)", storeloc2<id>, NODE);

In the above example, the NODEURL id as a web address is built-in with the code via the #define macro. Unless the above program is written to run only over the web and at this specific web address, it is not recommended to hard code the cel id. In general, this value should be read in at run time from some configuration file. This will allow the same compiled code to be run on the same environment with different locations (e.g. same web environment but with different web addresses). If the runtime environment changes, such as going from a distributed web environment to a shared-memory supercomputing platform, using a different configuration file is required but not enough. The code has to be recompiled with the corresponding library, with a pre-compiler that translates all NERWous C constructs to instructions that are supported on the new platform.

---

DOWN Exception

What happens if the cel location is down? We can capture this condition with the DOWN exception:

extern <cel> NODE;
main () {
     <mel at=NODE> int store;
     <!> Producer (store);
     <!> Consumer (store);
}
void Producer (<mel> int store) {
     int c;
     char *reason;
     try {
         while ( c = Produce() )
             <?>store = c; 
 
         reason = "No more product";
     }
     catch ( store<DOWN> ) {
         printf ("The DOWN exception is about %s", store<why>);
         reason = store<location> + " is down due to " + store<why>;
     }
     <close why=reason>store;
}
void Consumer (<mel> int store) {
    try {
         while ( 1 )
             Consume(<?>store);
     } 
     catch ( store<CLOSED> ) printf (%s, store<why>);
     catch ( store<DOWN> ) printf (%s, store<why>);
}

The Producer keeps running until it cannot Produce anymore, or until it detects that the cel that hosts the mel store is down, preventing it to deposit the produced item. When the DOWN exception is raised, the Producer prints the reason of the exception as recorded in the why property of the mel store, gets out of the while loop, and then closes the mel with the proper closure reason.

The Consumer task watches for two exceptions, the CLOSED exception and the DOWN exception. The former happens when the Producer invokes the close command, and the latter is due to the Consumer detecting that the hosting cell has been down. The why property due to the CLOSED exception is under the programmer's control as seen in the Producer code.

The why property due to the DOWN exception comes from the underlying environment. For example, in a distributed web environment, the web site that serves as the cel may be down, or there is a networking issue that prevents access to the web site. The NERWous C library for the distributed web collects these and other errors and reports back to the application level via the why property. Not all libraries can do such collection. In that case the why property for the DOWN exception will be blank.

---

Examples

The following examples make use of the mel location at attribute:

• GPU Accelerator Offloading
• Dining Philosophers

---

Previous Next Top