The MCS lock of Mellor-Crummey and Scott (1991), 23 pages. is a very efficient first-come first-served mutual-exclusion algorithm that uses the atomic hardware primitives fetch-and-store and compare-and-swap. However, it has the disadvantage that the calling thread must provide a pointer to an allocated record. This additional parameter violates the standard locking interface, which has only the lock as a parameter. Hence, it is impossible to switch to MCS without editing and recompiling an application that uses locks. This article provides a variation of MCS with the standard interface, which remains FCFS, called MCSH. One key ingredient is to stack allocate the necessary record in the acquire procedure of the lock, so its life-time only spans the delay to enter a critical section. A second key ingredient is communicating the allocated record between the acquire and release procedures through the lock to maintain the standard locking interface. Both of these practices are known to practitioners, but our solution combines them in a unique way. Furthermore, when these practices are used in prior papers, their correctness is often argued informally. The correctness of MCSH is verified rigorously with the proof assistant PVS, and experiments are run to compare its performance with MCS and similar locks.

SummaryThe C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating systems. This installation base and the programmers producing it represent a massive software engineering investment spanning decades and likely to continue for decades more. Nevertheless, C, which was first standardized almost 30 years ago, lacks many features that make programming in more modern languages safer and more productive. The goal of the C project (pronounced “C for all”) is to create an extension of C that provides modern safety and productivity features while still ensuring strong backward compatibility with C and its programmers. Prior projects have attempted similar goals but failed to honor the C programming style; for instance, adding object‐oriented or functional programming with garbage collection is a nonstarter for many C developers. Specifically, C is designed to have an orthogonal feature set based closely on the C programming paradigm, so that C features can be added incrementally to existing C code bases, and C programmers can learn C extensions on an as‐needed basis, preserving investment in existing code and programmers. This paper presents a quick tour of C features, showing how their design avoids shortcomings of similar features in C and other C‐like languages. Experimental results are presented to validate several of the new features.

The control-flow issues presented in this textbook are extremely relevant in modern computer languages and programming styles. In addition to the basic control-flow mechanisms, virtually all new computer languages provide some form of exceptional control flow to support robust programming introduced in this textbook. Also, concurrency capabilities are appearing with increasing frequency in both new and old programming languages, and are covered in this book. Understanding Control Flow: With Concurrent Programming Using C++ starts with looping, and works through each of the basic control-flow concepts, examining why each is fundamental and where it is useful. Time is spent on each concept according to its level of difficulty. Examples and exercises are also provided in this textbook. New programming methodologies are requiring new forms of control flow, and new programming languages are supporting these methodologies with new control structures, such as the concurrency constructs discussed in this textbook. Most computers now contain multi-threading and multi-cores, while multiple processors and distributed systems are ubiquitous all of which require advanced programming methodologies to takefull advantage of the available parallelism summarized in this textbook. Advance forms of control flow are becoming basic programming skills needed by all programmers, not just graduate students working in the operating systems or database disciplines. This textbook is designed for advanced-level students studying computer science and engineering. Professionals and researchers working in this field, specifically programming and software engineering, will find this book useful as a reference.

Linux and other open-source Unix variants (and their distributors) provide researchers with full-fledged operating systems that are widely used. However, due to their complexity and rapid development, care should be exercised when using these operating systems for performance experiments, especially in systems research. In particular, the size and continual evolution of the Linux code-base makes it difficult to understand, and as a result, decipher and explain the reasons for performance improvements. In addition, the rapid kernel development cycle means that experimental results can be viewed as out of date, or meaningless, very quickly. We demonstrate that this viewpoint is incorrect because kernel changes can and have introduced both bugs and performance degradations. This paper describes some of our experiences using Linux and FreeBSD as platforms for conducting performance evaluations and some performance regressions we have found. Our results show, these performance regressions can be serious (e.g., repeating identical experiments results in large variability in results) and long lived despite having a large negative effect on performance (one problem was present for more than 3 years). Based on these experiences, we argue: it is sometimes reasonable to use an older kernel version, experimental results need careful analysis to explain why a performance effect occurs, and publishing papers validating prior research is essential.

Two language mechanisms are presented and assessed for assisting understanding of exception complexity. First, passive and active exception assertions dynamically check if the reason for an exception raise matches with the purpose of a matching handler. A passive assertion is a check when an exception propagates out of a block it guards. The active form adds probabilistically injection of exceptions to provide more comprehensive testing. Second, runtime exception information is logged for dynamic query to check current handling status and provide a history of exceptional events.

Asynchronous exception propagation is a useful alternative form of communication among threads, especially if timely propagation is ensured. However, timely propagation is impossible for blocked threads. An approach is presented to transparently unblock threads to begin propagation of asynchronous termination and resumption exceptions. The approach does not require additional syntax, simplifies certain programming situations, and can improve performance.

This discussion addresses a number of urban legends about concurrency in an attempt to separate the myth from the fact. These legends are as follows: concurrent = parallel; coroutining = concurrency; synchronization = mutual exclusion; Dekker concurrency = library; inheritance anomaly = major concurrency problem; signalling = hints; spurious wakeup = efficiency. Identifying and understanding the fundamental concepts underlying concurrency is essential to the field. Equally important is not to confuse sequential and concurrent concepts. Finally, approaches based solely on efficiency are insufficient to justify a weak or difficult to use concurrent concept or construct. Copyright © 2005 John Wiley & Sons, Ltd.

A profiler is an important tool for understanding the dynamic behaviour of concurrent programs to locate problems and optimize performance. The best way to improve profiling capabilities and reduce the time to analyze a concurrent program is to use a target-specific profiler that understands the underlying concurrent runtime environment. A profiler for understanding execution of user and kernel level threads is presented, which is target-specific for the μC++ concurrency system. This allows the insertion of hooks into the μC++ data structures and runtime kernel to ensure crucial operations are monitored exactly. Because the profiler is written in μC++ and has an extendible design, it is easy for users to write new metrics and incorporate them into the profiler.

Article μDatabase: parallelism in a memory-mapped environment (research summary) Share on Authors: Peter A. Buhr Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1View Profile , Anil K. Goel Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1View Profile , Naomi Nishimura Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1View Profile , Prabhakar Ragde Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1View Profile Authors Info & Claims SPAA '96: Proceedings of the eighth annual ACM symposium on Parallel Algorithms and ArchitecturesJune 1996 Pages 196–199https://doi.org/10.1145/237502.237547Online:24 June 1996Publication History 0citation143DownloadsMetricsTotal Citations0Total Downloads143Last 12 Months0Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

ration cannot beimplemented in a safe and portable way outside of a translator (compiler, assembler, etc.). Without languagebasedconstructs to indicate concurrent semantics, an underlying translator may generate code that is correctfor sequential execution but incorrect for concurrent execution. Without examining the generated code aftereach translation, a programmer cannot assess and guarantee the correctness of even a well formed program.The proof does not assume a particular programming ...

The main objective of this work was an efficient methodology for constructing low-level database tools that are built around a single-level store implemented using memory mapping. The methodology allowed normal programming pointers to be stored directly onto secondary storage, and subsequently retrieved and manipulated by other programs without the need for relocation, pointer swizzling or reading all the data. File structures for a database, e.g. a B-Tree, built using this approach are significantly simpler to build, test, and maintain than traditional file structures. All access methods to the file structure are statically type-safe and file structure definitions can be generic in the type of the record and possibly key(s) stored in the file structure, which affords significant code reuse. An additional design requirement is that multiple file structures may be simultaneously accessible by an application. Concurrency at both the front end (multiple accessors) and the back end (file structure partitioned over multiple disks) are possible. Finally, experimental results between traditional and memory mapped files structures show that performance of a memory mapped file structure is as good or better than the traditional approach.

A programming language that lacks facilities for concurrent programming can gain those facilities in two ways: the language can be extended with additional constructs, which will reflect a particular model of concurrency, or libraries of types and routines can be written with different libraries implementing different models. This paper examines the two approaches, for object-oriented and non-object-oriented languages. Examples show that concurrency interacts extensively with traditional programming language constructs, and that general elementary facilities for concurrency must be implemented at extremely low levels—the assembly language level, in some cases—and hence that safe support for concurrency requires language extension.