Computing is a large and growing presence in society in 2020, and like many others, we see a strong demand from non-computing majors for "CS For All" courses. Unlike many others, we do not feel that putting traditional programming first is the best way to do this. Instead, we are rethinking the way we introduce computing to allow a broad audience to engage with this discipline.

Summary This paper shows how to simplify and speed up distributed JR program start‐up. We accomplish this goal by extending JR's operation abstraction so that it includes the creation of virtual machines and remote objects, the key components in distributed JR programs. This extension is conceptually simple, fits well with the rest of the JR language, and provides additional flexibility. Extending JR's operation abstraction yields a considerably less complex solution and a simpler implementation than other approaches, which would have led to redundant or ad‐hoc language mechanisms. The extension also allows for reduced distributed JR program start‐up costs because the creation of virtual machines and remote objects can now be done in parallel. This paper also describes how we have simulated this extension and have implemented a prototype that provides this extension. These reflect closely what we would need to do to actually include the extension within the standard JR implementation. Using the simulation and prototype, we obtained performance data on a few typical distributed applications written to use the extension. The data show large reductions, ranging from about 50% to 95%, in distributed JR program start‐up times. Our experiments also explored a few strategies to further reduce start‐up times, but, among our strategies, the straightforward strategies seem the best. This paper also discusses design alternatives for creating virtual machines and remote objects. Our experience suggests that the proposed extension to JR's operation abstraction is actually worthwhile to add to the standard JR language and implementation.

Inexperienced and novice programmers in CS 1 are often faced with the expectation that they will be able to decompose a problem into subproblems, solve these subproblems independently, and then recompose these solutions. As with programming in general, decomposition is a skill that benefits from explicit instruction and that must be practiced to see improvement. This paper introduces a term-long project approach to CS 1 that emphasizes program decomposition. Existing software quality metrics are used to assess student decomposition progression through the project and to compare the decomposition skills of students in courses using the term-long project approach against those in courses using a more typical "stand-alone" project approach.

When teaching introductory computing courses, we are often guilty of writing rudimentary programming assignments - those meant to illustrate one simple language feature, comprised mostly of code that will never be used beyond the assignment. Admittedly, first-year computing students must navigate a myriad of challenges, sometimes learning both imperative and object-oriented programming, in addition to mastering syntax, logic,debugging, and testing. To tackle the difficulties of developing CS 1 and CS 2 courses that engage students in learning while addressing the numerous course objectives, we chose to challenge students to create virtual worlds in one large comprehensive two-quarter long programming project. Students were granted creative freedom within a framework that gradually introduced many programming skills and that required the mastery of object-oriented programming and some engaging algorithms. We present the curriculum, performance comparisons, and observations. Overall, we consider the experimental courses a success that will have an impact on our department's future curricular offerings.

Summary Many message passing languages and packages include some form of synchronous invocation. In a synchronous invocation, the invoker waits for the invocation's servicer to pass back results. A synchronous invocation can be viewed as a pair of asynchronous invocations: one—initiating the computation—with parameter values from the invoker to the servicer and the other—once the requested computation has completed—with the ‘go‐ahead’ and return value from the servicer to the invoker. The target of the latter invocation is known as thereply operation, and a reference to it is known as areply capability. This paper addresses the issues of making such reply capabilities directly accessible to user code. It presents the design and prototype implementation of a new version of the JR concurrent programming language, called xJR, in which the reply capability can be explicit. This paper gives xJR examples, including realistic ones, to highlight the additional flexibility the new features offer (such as a non‐lexical reply). These additional features do not impact the run‐time performance of existing JR features and can even lead to more efficient code in some programming scenarios. Our experience with the prototype implementation indicates that an actual implementation would be fruitful and would preserve the prototype's performance advantages. Copyright © 2015 John Wiley & Sons, Ltd.

Summary Message passing notations (language, package, etc.) typically include some form of asynchronous or synchronous invocation. In a synchronous invocation, the invoker waits for the invocation's servicer to pass back results. Some message passing notations also include early reply or deferred reply (including forwarding), which alters how and when the servicer passes back its results; this additional flexibility is useful in realistic applications. It is well known how to transform a synchronous invocation into only asynchronous invocations. This paper extends such transformations to early reply and forward. This paper also describes the use of these transformations within the implementations of programming notations. Using the transformation simplifies the implementation without significantly affecting run‐time costs. Copyright © 2015 John Wiley & Sons, Ltd.

Abstract The global quiescence (GQ) of a distributed computation (or distributed termination detection) is an important problem. Some concurrent programming languages and systems provide GQ detection as a built‐in feature so that programmers do not need to write special synchronization code to detect quiescence. This paper introducespartial quiescence(PQ), which generalizes quiescence detection to a specified part of a distributed computation. PQ is useful, for example, when two independent concurrent computations that both rely on GQ need to be combined into a single program. The paper describes how we have designed and implemented a PQ mechanism within an experimental version of the JR concurrent programming language, and have gained experience with several representative applications. Our early results are promising qualitatively and quantitatively. Copyright © 2007 John Wiley & Sons, Ltd.

Abstract Two models of thread execution are the general concurrent programming execution model (CP) and the cooperative multithreading execution model (CM). CP provides nondeterministic thread execution where context switches occur arbitrarily. CM provides threads that execute one at a time until they explicitly choose to yield the processor. This paper focuses on a classic application to reveal the advantages and disadvantages of load balancing during thread execution under CP and CM styles; results from a second classic application were similar. These applications are programmed in two different languages (SR and Dynamic C) on different hardware (standard PCs and embedded system controllers). An SR‐like run‐time system, DesCaRTeS, was developed to provide interprocess communication for the Dynamic C implementations. This paper compares load balancing and non‐load balancing implementations; it also compares CP and CM style implementations. The results show that in cases of very high or very low workloads, load balancing slightly hindered performance; and in cases of moderate workload, both SR and Dynamic C implementations of load balancing generally performed well. Further, for these applications, CM style programs outperform CP style programs in some cases, but the opposite occurs in some other cases. This paper also discusses qualitative tradeoffs between CM style programming and CP style programming for these applications. Copyright © 2004 John Wiley & Sons, Ltd.

Java provides a clean object-oriented programming model and allows for inherently system-independent programs. Unfortunately, Java has a limited concurrency model, providing only threads and remote method invocation (RMI).The JR programming language extends Java to provide a rich concurrency model, based on that of SR. JR provides dynamic remote virtual machine creation, dynamic remote object creation, remote method invocation, asynchronous communication, rendezvous, and dynamic process creation. JR's concurrency model stems from the addition of operations (a generalization of procedures) and JR supports the redefinition of operations through inheritance. JR programs are written in an extended Java and then translated into standard Java programs. The JR run-time support system is also written in standard Java.This paper describes the JR programming language and its implementation. Some initial measurements of the performance of the implementation are also included.

Abstract This paper presents a comparison of the cooperative multithreading model with the general concurrent programming model. It focuses on the execution time performance of a range of standard concurrent programming applications. The overall results are mixed. In some cases, programs written in the cooperative multithreading model outperform those written in the general concurrent programming model. The contributions of this paper are twofold. First, it presents a thorough analysis of the performances of applications in the different models, i.e. to explain the criteria that determine when a program in one model will outperform an equivalent program in the other. Second, it examines the tradeoffs in writing programs in the different programming styles. In some cases, better performance comes at the cost of more complicated code. Copyright © 2003 John Wiley & Sons, Ltd.

Java provides a clean object-oriented programming model and allows for inherently system-independent programs. Unfortunately, Java has a limited concurrency model, providing only threads and remote method invocation (RMI). The JR programming language extends Java to provide a rich concurrency model. JR provides dynamic remote virtual machine creation, dynamic remote object creation, remote method invocation, asynchronous communication, rendezvous, and dynamic process creation. JR programs are written in an extended Java and then translated into standard Java programs. The JR run-time support system is also written in standard Java. This paper describes the JR programming language and its implementation. Some initial measurements of the performance of the implementation are also included.