Welcome
» The NERW Concurrency Model
At the heart of any concurrent system is the idea that several "things" executing at the same time. In the NERW model, the Processing Element (pel) abstracts this idea of execution. A pel executes on a physical computer. The pel does not abstract the computer itself, but instead the thread, task, application process, container, or whatever unit of execution in the computer. In other words, the pel represents the logical aspect of the execution , while the locality aspect of it, the computer, is represented by another NERW element, the Computer Element (or cel).
Concurrency happens when there is more than one pel running at the same time. The pels can execute the same code (as in parallel loops), or different code (as in a concurrent application).
To execute, a pel must reside somewhere. This "somewhere" is represented by the computer element (cel). In general, the CHAOS runtime takes care of assigning an executing pel to a hosting cel. However, the NERW model allows the programmer to specify this assignment at compile time, and even the user to customize this assignment at run time. For example, a pel drawing a circle should be assigned to a cel with access to a graphical display so that the tendered circle can be viewed, while a computational heavy pel should be best assigned to a cel with floating-point capability.
To execute, a pel may need to get the input data from another pel. After execution, it may need to give its resulting data to another pel. This is accomplished via the memory element (mel). In the first case, a pel reads from a mel, and in the second case, writes to a mel. If a read is not possible (due to mel empty or locked), or a write is not possible (due to mel buffer full or locked), a pel has to wait. Thus a pel should only access a mel only at the last moment before need. Another strategy is for a pel to fork a delegate pel to do the mel waiting for it while it continues with other meaningful work.
Pel Implementations
See Pel in NERWous C.
Previous Next Top
At the heart of any concurrent system is the idea that several "things" executing at the same time. In the NERW model, the Processing Element (pel) abstracts this idea of execution. A pel executes on a physical computer. The pel does not abstract the computer itself, but instead the thread, task, application process, container, or whatever unit of execution in the computer. In other words, the pel represents the logical aspect of the execution , while the locality aspect of it, the computer, is represented by another NERW element, the Computer Element (or cel).
Concurrency happens when there is more than one pel running at the same time. The pels can execute the same code (as in parallel loops), or different code (as in a concurrent application).
To execute, a pel must reside somewhere. This "somewhere" is represented by the computer element (cel). In general, the CHAOS runtime takes care of assigning an executing pel to a hosting cel. However, the NERW model allows the programmer to specify this assignment at compile time, and even the user to customize this assignment at run time. For example, a pel drawing a circle should be assigned to a cel with access to a graphical display so that the tendered circle can be viewed, while a computational heavy pel should be best assigned to a cel with floating-point capability.
To execute, a pel may need to get the input data from another pel. After execution, it may need to give its resulting data to another pel. This is accomplished via the memory element (mel). In the first case, a pel reads from a mel, and in the second case, writes to a mel. If a read is not possible (due to mel empty or locked), or a write is not possible (due to mel buffer full or locked), a pel has to wait. Thus a pel should only access a mel only at the last moment before need. Another strategy is for a pel to fork a delegate pel to do the mel waiting for it while it continues with other meaningful work.
Pel Implementations
See Pel in NERWous C.
Previous Next Top
Since NEWR is for a concurrent model it deserves an incisive description of concurrency. “At the heart of a concurrent model is every 'thing' executing at the same time.” Here you describe concurrent execution as parallel execution. In the last blog you explained concurrency and parallelism better.
ReplyDeleteIn the third paragraph, you seems again to suggest a model for an operating system rather than for a language. Even in a general operating system, allowing programmer the ability to allocate or migrate pel to cel based on the type of cel or for load balance or error recovery implies that the model needs define different type of cel and somehow export that information to the user. In general, the OS hides the hardware complexity from user, and knows what resources are available and allocates them accordingly. Isn't that the reason why we need a general OS? The trouble with this model is that it assumes that the programer only write a single program (in C, one main function) to handle all different applications with different hardware configurations.
The last paragraph implies that your pel is the same as the OS process. It needs not be. That is where a language runtime come in. Otherwise, why design a new language when a library would be sufficient.
One more thought on concurrency, if you think the readers need an explanation of concurrency and parallelism, then they should be explained once and for all at the earliest opportunity. Later in the document, they should be referred to using words such as concurrent, concurrently, concurrency, and the likes.
ReplyDeleteThe following paragraph has been deleted per Chanh Pham's comment:
ReplyDelete"While a pel needs residence in a cel, the NERW model does not require that this residence be fixed. If supported by the underlying CHAOS run-time environment, a pel can migrate from one cel to another to achieve fault tolerance or load balancing."