Pipes

AnecdotesNotes on the History of Fork and Join Linus Nyman (bio) and Mikael Laakso (bio) As part of a PhD on code forking in open source software, Linus Nyman looked into the origins of how the practice came to be called forking.1 This search led to the early history of the fork system call. Having not previously seen such a history published, here we look back at the birth of the fork system call to share what was learned, as remembered by its pioneers. The fork call allows a process (or running program) to create new processes. The original is deemed the parent process, and the newly created one its child. On multiprocessor systems, these processes can run concurrently in parallel.2 Since its birth 50 years ago, the fork has remained a central element of modern computing, both with regard to software development principles and, by extension, to hardware design, which increasingly accommodates parallelism in process execution. Fork System Call Imagined The year was 1962. Melvin Conway, later to become known for Conway’s law,3 was troubled by what seemed an unnecessary inefficiency in computing. As Conway recalled, I was in the US Air Force at the time—involved with computer procurement—and I noticed that no vendor was distinguishing between “processor” and “process.” That is, when a proposal involved a multiprocessor design, each processor was committed to a single process.4 By late 1962, Conway had begun contemplating the idea of using a record to carry the status of a process. In the spring of 1963, “as an intellectual exercise,” Conway wrote a paper suggesting a means of implementing parallel processing in a multiprocessor system design, using what he called “fork and join” system calls. Figure 1 shows the original illustration of the fork and join system call. Conway presented a paper, “A Multiprocessor System Design,” later that fall at the American Federation of Information Processing Societies (AFIPS) Joint Computer Conference, and it was published in the conference proceedings.5,6 Conway explained the basic idea in the paper: Fundamental to the concepts presented here is the principle, not yet commonly accepted, that parallel paths in a program need not bear fixed relationships to the processors of a multiprocessor system executing that program.7 Although Conway had not come across anyone offering a solution to this inefficiency, he is nonetheless modest about the novelty of his suggestion: Of course I do not claim to have invented that idea, since it must be present in all implementations in some form or other.4 Indeed, there were some who had addressed the issue before him. In a footnote in the article, Conway noted that “the fork-join notion has been around for a while,” albeit under different names, such as branch in the CL-II and Burroughs D825 AOSP computers, SIMU in the Gamma 60 computer, and branch transfer or BRT in the conceptual machine discussed by P. Richards.8 Reflecting on that footnote, Conway stated: I only vaguely remember the origin of the footnote. The fact of its placement as a footnote suggests to me that it was added after submission of the paper at the urging of the editors, who may have noted that the technical concept was already in use. I conjecture that I added the footnote to assert the first use of the word in this technical context. If that is indeed the history of the footnote, the acceptance of my wording by the editors suggests their consent.4 In fact, there was a second paper at that same 1963 Fall Joint Computer Conference in which the terms “fork” and “join” were also used.9 Although the idea was not Conway’s alone, the publication of his paper describing it seems to have codified the idea and become the impetus for its widespread implementation in later computer systems. The system call’s popularity was not due to Conway himself implementing the fork—he did not. Nor was it due to the paper having had a significant impact at the conference—Conway recalled that it did not. Rather, it appears due to the paper finding its way to Project Genie. Project Genie Project Genie...

It is well-known that multiprocessor systems are vastly more difficult to program than systems that support sequential programming models. In a 1998 paper[11] this author argued that six important principles for supporting modular software construction are often violated by the architectures proposed for multiprocessor computer systems. The Fresh Breeze project concerns the architecture and design of a multiprocessor chip that can achieve superior performance while honoring these six principles.The envisioned multiprocessor chip will incorporate three ideas that are significant departures from mainstream thinking about multiprocessor architecture: (1) Simultaneous multithreading has been shown to have performance advantages relative to contemporary superscalar designs. This advantage can be exploited through use of a programming model that exposes parallelism in the form of multiple threads of computation. (2) The value of a shared address space is widely appreciated. Through the use of 64-bit pointers, the conventional distinction between "memory" and the file system can be abolished. This can provide a superior execution environment in support of program modularity and software reuse, as well as supporting multi-user data protection and security that is consistent with modular software structure. (3) No memory update; cycle-free heap. Data items are created, used, and released, but never modified once created. The allocation, release, and garbage collection of fixed-size chunks of memory will be implemented by efficient hardware mechanisms. A major benefit of this choice is that the multiprocessor cache coherence problem vanishes: any object retrieved from the memory system is immutable. In addition, it is easy to prevent the formation of pointer cycles, simplifying the design of memory management support.

The Real-Time Specification for Java (RTSJ) is silent on multiprocessor issues. It attempts not to preclude multiprocessor implementations but provides no direct support. Many areas of the RTSJ leave an implementation considerable freedom on how it provides the defined functionality. One such area is the asynchronous event handling (AEH) model. Events are fired and associated handlers are scheduled for execution in response; handlers have defined scheduling parameters and deadlines. The primary goal of the AEH model is to support a lightweight real-time concurrency model. Hence handlers, in general, do not have dedicated threads. Rather, the implementation is responsible for ensuring that all handlers meet their deadlines. Typically real-time threads are assigned to execute handlers by the implementation. This paper discusses the issues associated with implementing the AEH model on multiprocessor systems. The emphasis here is on achieving a lightweight model. A model is lightweight if it is able to meet the deadlines of all handlers with as few as possible real-time threads. In the RTSJ this is made more complicated because asynchronous event handlers are allowed to suspend themselves (for example, by waiting on a monitor condition). Such handlers are called blocking handlers. Most of an implementation's freedom comes from being able to optimize the support for those handlers that do not block. The paper first examines all possible releasing sequences of non-blocking handlers on multiprocessor systems. Based on this, it proposes an efficient and scalable AEH mapping model for multiprocessor systems, which limits the number of real-time threads even in the worst case while retaining the schedulability of the system. The proposed model is then examined to prove its safety and liveness requirements using a model checking tool, UPPAAL. The verification and simulation results of the model indicate that the safety and liveness requirements are satisfied. Most importantly, this paper derives the proposed model's greatest lower and least upper bounds of real-time threads required to execute a given number of non-blocking handlers. The greatest lower bound is equal to the number of processors, and the least upper bound is equal to the number of processors times that of the priority levels in the system. In the model, the number of real-time threads required to execute a given number of non-blocking handlers is restricted to between these two bounds depending on the releasing sequence of handlers. Even in the worst case, the model requires the least upper bound of real-time threads which is, in most cases, considerably less than the actual number of handlers in the system. This, in turn, enables the proposed model to be efficient and scalable by reducing time and space overheads, compared with a traditional 1:1 AEH mapping model where each handler is mapped to a single thread.

Code Reuse Attacks (CRAs) are dangerous exploitation strategies that allow attackers to compose malicious programs out of existing application and library code gadgets, without requiring code injection. Previously, researchers explored hardware-assisted protection schemes that track attack signatures to identify malicious behavior. This paper makes two main contributions. First, we show that previously proposed signature-based schemes are impractical because they do not always distinguish attack patterns from the behavior of benign programs. Second, we demonstrate that instead of tracking attack signatures, a more robust defense mechanism is to track legitimate usage of system calls and ABI compliance in hardware, and detect deviations from established conventions as possible attacks. We propose two specific tracking mechanisms: the setting of arguments for system calls and register usage across function calls. We demonstrate that our solution severely hinders practical CRAs and completely stops code-reuse execution of sensitive system calls like mprotect. Our solution imposes very low performance overhead and modest design complexity.

A multi-layer, X.25 based protocol has been implemented on a multiprocessor system. The higher layer protocol resides in the system processor while the lower level protocol (X.25 levels 2 and 3) runs on a peripheral processor. This paper focuses on the boundary between the system and peripheral processors. It discusses how flow control is done, how control information is passed across the boundary, and the synchronization problems that arose. In addition, it describes effects on performance resulting from splitting the protocol across the two processors.

The author presents strategies for static loop decomposition and scheduling as well as computer-assisted run-time scheduling that take into account, in addition to the cost of performing operations, the overhead costs associated with a decomposition and schedule. An algorithm for static decomposition of multidimensional loops based on the operation execution costs, communication costs, and synchronization costs is discussed. Synchronization instructions are introduced to ensure correct program execution following program decomposition. An algorithm for determining the explicit synchronization instruction that should be introduced to ensure correct execution of a program with arbitrarily nested loops is presented. Techniques for reducing run-time scheduling and communication and synchronization costs due to self-scheduling of multidimensional loops are also presented. Experiments performed on the Encore multiprocessor system demonstrate that the techniques developed can reduce overhead costs. >

System calls have been proved to be important evidence for analyzing the behavior of running applications. However, application behavior analyzers which investigate the majority of system calls usually suffer from severe system performance deterioration or frequent system crashes. In the presented study, a light weighted analyzer is approached by two avenues. On the one hand, the computation load to monitor the system calls are considerably reduced by limiting the target functions to two specific groups: file accesses and Windows Registry accesses. On the other hand, analytical accuracy is achieved by deep inspection into the string parameters of the function calls, where the proximity of the programs are evaluated by the newly proposed kernel functions. The efficacy of the proposed approach is evaluated on real world datasets with promising results reported.KeywordsFTreekernel on structured dataregistry analysissequence analysissystem call analysis

The goal of the work reported is to construct a framework that supports the development of concurrent applications. The paper presents the operational structure of an object based architectural system, illustrates the different kinds of relationships that may exist between the objects in an operational structure and how communication between the objects in such relationships is solved by message passing. Examples of synchronous, asynchronous and remote invocation types of process interaction models are also shown.

This paper critically discusses the different choices that have to be made when defining a fault model for an object-oriented programming language. We consider in particular the ABS language, and analyze the interplay between the fault model and the main features of ABS, namely the cooperative concurrency model, based on asynchronous method invocations whose return results via futures, and its emphasis on static analysis based on invariants.

Object oriented simulation is becoming more and more important, as object based software architectures and platforms are gaining popularity. A prototype CASE environment is under development at CSELT which allows users to specify applications according to the ACE computational model, an object oriented based on the concept of Building Block, in turn derived by the TINA-C architecture. One of the features provided by ACE environment is the simulation of the specifications. The proposed approach to simulation is to first translate the object oriented specification to the process level, to use an already available simulation engine with a good efficiency and reliability and then bring the simulation results back to the object level. The semantics of the ACE language, which includes sophisticated primitives, like asynchronous method invocation, concurrent objects and method guards has been mapped at the process level using appropriate templates. The results show that a good efficiency has been obtained: around one hundred object level events per second are simulated on a state of the art workstation.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

When used to simulate manufacturing systems, most existing parallel simulation languages cannot easily implement some features of those systems, such as the scheduling rules of a machine or the sharing of operators by multiple machines. The paper presents the design and implementation of a parallel object oriented manufacturing simulation language, called POMSim. A POMSim simulation is developed by using the concept of classes (entity types) and inheritance to support iterative design of efficient simulation models. POMSim completely hides all the details of parallel simulation, and provides simple and direct constructs to efficiently model the scheduling rules in manufacturing simulations. It also provides asynchronous method invocation and synchronous function call. POMSim libraries predefine a set of basic classes for manufacturing simulation, each of which represents a particular component in the physical manufacturing system.

Some radar image processing algorithms such as shape-from-shading are particularly compute-intensive and time consuming. If, in addition, a data set to be processed is large, then it may make sense to perform the processing of images on multiple workstations or parallel processing systems. We have implemented shape-from-shading, stereo matching, resampling, gridding and visualization of terrain models in such a manner that they execute either on parallel machines or on clusters of workstations. We were motivated by the large image data set from NASA's Magellan mission to planet Venus, but received additional inspiration from the European Union's Center for Earth Observation program (CEO) and Austria's MISSION initiative for distributed processing of remote sensing images on remote workstations, using publicly accessible algorithms. We have developed a multi-processor approach that we denote as CDIP for Concurrent and Distributed Image Processing. The speedup for image processing tasks increases nearly linearly with the number of processors, be they on a parallel machine or arranged in a cluster of distributed workstations. Our approach adds benefits for users of complex image processing algorithms: the efforts for code porting and code maintenance are reduced and the necessity for specialized parallel processing hardware is eliminated.

Compilers for current programming languages enforce rigid restrictions on changes, during the compilation of a statement, in the set of associations between names and declarations, that is, on changes in the compile-time environment of the statement. These restrictions inhibit the writing of well-structured, modular programs, because such programs tend to require frequent switching between the environments associated with different modules. With current compilers, arbitrary switching of environments must be handled by means of macros at compile time or deferred until run time. Conventional macros are difficult to use in situations where it is desirable that the macro writer and the macro user be ignorant about each other's programs. When deferred until run time, frequent switching of environments becomes costly owing to the overhead associated with subroutine calls. In order to encourage the compartmentalization of program information and at the same time to allow efficient code generation, we propose the relaxation of present restrictions on changes in the compile-time environment. Specifically, we propose that a group of declarations can be defined as an environment and that arbitrary pieces of program text can state within which environment they are to be compiled. With such a mechanism, program text can be intermixed by means of macros without having to make the relevant declarations global or having to repeat the declarations in places other than the environment's definition.

SummaryMulticore network processors have been playing an increasingly important role in computational processes, which emphasize on scalability and parallelism of the systems, in distributed environments especially in Internet‐based delay‐sensitive applications. It is an important but unsolved issue, however, to efficiently schedule tasks in network processors with multicore and multithread for improving the system throughput as much as possible. Profiling can gather runtime environment information and guide the compiler to optimize programs through scheduling tasks based on the runtime context. This paper proposes a profiling‐based task scheduling approach, targeting on improving the throughput of multicore network processor (Intel IXP) systems in the balanced pipeline way. In this work, we investigate a profiling‐based task scheduling framework, a task scheduling algorithm, and a set of performance models. Our task allocation scheme maps tasks onto the pipeline architecture and multiple threads of network processors in parallel, which incorporates the profiling context and global thread refinement. We evaluate our task scheduling algorithm by implementing representative network applications on the Intel IXP network processor. Experimental results demonstrate that our algorithm is able to schedule tasks in a balanced pipeline fashion and achieve the high throughput and data transmission rate. Copyright © 2012 John Wiley &amp; Sons, Ltd.

: We present an efficient encoding of core Java constructs in a simple, implementable typed intermediate language. The encoding, after type erasure, has the same operational behavior as a standard implementation using v-tables and self-application for method invocation. Classes inherit super-class methods with no overhead. We support mutually recursive classes while preserving separate compilation. Our strategy extends naturally to a significant subset of Java, including interfaces and privacy. The formal translation using Featherweight Java allows comprehensible type-preservation proofs and serves as a starting point for extending the translation to new features. Our work provides a foundation for supporting certifying compilation of Java-like class-based languages in a type-theoretic framework.