© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.

Slides:



Advertisements
Similar presentations
Programming Paradigms and languages
Advertisements

Programming Languages and Paradigms
Chapter 8 High-Level Programming Languages. 8-2 Chapter Goals Describe the translation process and distinguish between assembly, compilation, interpretation,
Exception Handling. Background In a perfect world, users would never enter data in the wrong form, files they choose to open would always exist, and code.
Programming Languages Marjan Sirjani 2 2. Language Design Issues Design to Run efficiently : early languages Easy to write correctly : new languages.
Program Representations. Representing programs Goals.
© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.
Exception Handling. Background The fact that software modules should be robust enough to work under every situation. The exception handling mechanism.
Chapter 2: Algorithm Discovery and Design
Reasons to study concepts of PL
Programming Languages Structure
State Machines Timing Computer Bus Computer Performance Instruction Set Architectures RISC / CISC Machines.
1 New Architectures Need New Languages A triumph of optimism over experience! Ian Watson 3 rd July 2009.
Copyright © 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Java Software Solutions Foundations of Program Design Sixth Edition by Lewis.
1 Sharing Objects – Ch. 3 Visibility What is the source of the issue? Volatile Dekker’s algorithm Publication and Escape Thread Confinement Immutability.
C++ for Engineers and Scientists Third Edition
ECE122 L17: Method Development and Testing April 5, 2007 ECE 122 Engineering Problem Solving with Java Lecture 17 Method Development and Testing.
Chapter 2: Algorithm Discovery and Design
Chapter 2: Algorithm Discovery and Design
© 2009 Mathew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.
Advances in Language Design
Language Evaluation Criteria
CSE 425: Intro to Programming Languages and their Design A Few Key Ideas No particular language is a prerequisite for this course –However you should be.
Dr. Ken Hoganson, © August 2014 Programming in R STAT8030 Programming in R COURSE NOTES 1: Hoganson Programming Languages.
MT311 Java Programming and Programming Languages Li Tak Sing ( 李德成 )
Imperative Programming
GENERAL CONCEPTS OF OOPS INTRODUCTION With rapidly changing world and highly competitive and versatile nature of industry, the operations are becoming.
© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.
Design-Making Projects Work (Chapter7) n Large Projects u Design often distinct from analysis or coding u Project takes weeks, months or years to create.
IT253: Computer Organization Lecture 4: Instruction Set Architecture Tonga Institute of Higher Education.
CSC3315 (Spring 2009)1 CSC 3315 Programming Languages Hamid Harroud School of Science and Engineering, Akhawayn University
Chapter 2: Algorithm Discovery and Design Invitation to Computer Science, C++ Version, Third Edition.
Invitation to Computer Science, Java Version, Second Edition.
Lecture Set 5 Control Structures Part D - Repetition with Loops.
© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.
University of Houston-Clear Lake Proprietary© 1997 Evolution of Programming Languages Basic cycle of improvement –Experience software difficulties –Theory.
Programming Language C++ Xulong Peng CSC415 Programming Languages.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages.
CSCI-383 Object-Oriented Programming & Design Lecture 13.
Compiler Chapter# 5 Intermediate code generation.
Introduction to Object Oriented Programming CMSC 331.
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
Transactional Coherence and Consistency Presenters: Muhammad Mohsin Butt. (g ) Coe-502 paper presentation 2.
Consider the program fragment below left. Assume that the program containing this fragment executes t1() and t2() on separate threads running on separate.
8-1 Compilers Compiler A program that translates a high-level language program into machine code High-level languages provide a richer set of instructions.
Object-Oriented Programming Chapter Chapter
MT311 Java Application Development and Programming Languages Li Tak Sing ( 李德成 )
Programmability Hiroshi Nakashima Thomas Sterling.
Copyright © 2005 Elsevier Object-Oriented Programming Control or PROCESS abstraction is a very old idea (subroutines!), though few languages provide it.
 In the java programming language, a keyword is one of 50 reserved words which have a predefined meaning in the language; because of this,
Introduction to Object-Oriented Programming Lesson 2.
13-1 Chapter 13 Concurrency Topics Introduction Introduction to Subprogram-Level Concurrency Semaphores Monitors Message Passing Java Threads C# Threads.
Review of Parnas’ Criteria for Decomposing Systems into Modules Zheng Wang, Yuan Zhang Michigan State University 04/19/2002.
Data Design and Implementation. Definitions Atomic or primitive type A data type whose elements are single, non-decomposable data items Composite type.
Introduction to OOP CPS235: Introduction.
(1) ICS 313: Programming Language Theory Chapter 11: Abstract Data Types (Data Abstraction)
1 Why Threads are a Bad Idea (for most purposes) based on a presentation by John Ousterhout Sun Microsystems Laboratories Threads!
M1G Introduction to Programming 2 2. Creating Classes: Game and Player.
Chapter 2: Algorithm Discovery and Design Invitation to Computer Science.
C# Fundamentals An Introduction. Before we begin How to get started writing C# – Quick tour of the dev. Environment – The current C# version is 5.0 –
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
Riyadh Philanthropic Society For Science Prince Sultan College For Woman Dept. of Computer & Information Sciences CS 251 Introduction to Computer Organization.
Chapter 1: Preliminaries Lecture # 2. Chapter 1: Preliminaries Reasons for Studying Concepts of Programming Languages Programming Domains Language Evaluation.
C++ for Engineers and Scientists Second Edition Chapter 4 Selection Structures.
Type Checking, and Scopes
Concurrency in Programming Languages
Expressions Chapter 4 Copyright © 2008 W. W. Norton & Company.
Programming Languages, Preliminaries, History & Evolution
Presentation transcript:

© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig E Rasmussen

© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 2 Chapter 5 Objectives Examine high-level language constructs and how concurrency impacts them. Introduce the cognitive dimensions framework for evaluating language features.

Outline Familiar language constructs Evaluating language constructs Interactions with concurrency © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 3

Language constructs What is a “language construct”? These are the building blocks that languages provide programmers to put programs together. Examples: –loop operators (for, while, do) –conditionals (if/then/else, switch, case) –arithmetic operations –types –data structures (arrays, records, containers) © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 4

Purpose The purpose of these constructs is to raise the abstraction level that programmers work at. The compiler for a language is responsible for converting these down to a lower level machine representation. –Or virtual machine representation, which is becoming commonplace in environments like Java and.NET. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 5

Abstraction layers © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 6

Expressions Expressions represent computations on variables. Typically they are composed of unary and binary operations on data objects. They provide a way to concisely describe complex computations, instead of requiring the programmer to decompose them into the sequence of actual operations required to implement them. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 7

Example expression Equations like the one below appear all the time in code for financial applications, games, simulations, graphics, etc… Expressions are used to represent this in code: © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 8 sum += pow(a+i,3.0) * (i * b + (c/d));

Example expression That simple expression will likely be implemented with much more verbose, low level operations: Expressions support this abstraction over the verbose sequence of little operations. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 9 tmp = c/d; tmp2 = i*b; tmp = tmp + tmp2; tmp2 = a+i; tmp3 = a+i; tmp2 = tmp2 * tmp2; tmp2 = tmp2 * tmp3; tmp = tmp * tmp2; sum = sum + tmp; sum += pow(a+i,3.0) * (i * b + (c/d));

Expressions and concurrency Expressions are turned into sequences of smaller operations. As a result, evaluating an expression may itself not be an atomic operation. If an expression references a location in memory that is shared with other threads of execution, there is potential for conflicts. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 10

Example This expression references the value at a[1] twice. If the compiler doesn’t emit code that atomically reads and caches the value stored there, then the thread executing the expression may read the location at two different times. The result could be impacted by another thread updating the location between reads. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 11 x = a[1] + (a[0] * (b[1] / a[1]))

Side-effects Side-effects are a common source of complication for concurrent programming. In the last example, the fact that the expression directly references memory that another thread can modify means that threads can cause effects visible to other threads. An operation that changes the state of the world (either memory or IO) can be said to have side- effects. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 12

Side-effects Code that performs only computations with no side effects is often called “pure”. Impure code does more than compute – it has a tangible effect on the world. Functional languages often devote more attention to purity than other language families. –For example, in Haskell side effects are explicitly indicated by the type that a computation has. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 13

Side-effects Why do side effects complicate concurrency? Effects make the result of a program highly dependent on the order by which program statements are executed across interacting threads. The less dependencies that exist between statements, the more flexibility that the compiler or programmer have to exploit concurrency. –Side-effects induce dependencies between threads. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 14

Control flow primitives Expressions define computations, while control flow primitives help control the sequences of computations occur. Loops are a common example – instead of enumerating all repetitions of a block of code, the loop represents one copy and an expression representing how many times to repeat it. –Some loops, like for loops, also provide parameters for each iteration of the loop body. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 15

Control flow primitives Conditionals are another example: –Simple branching via if-then-else –More general branching via switch or case statements. Control flow primitives can reveal potential concurrency in a program. Loops are the most common control flow primitive that reveals concurrency. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 16

Loops A loop repeats a sequence of statements. In some cases, the Nth iteration uses the results of the (N-1)th iteration. –This means that there is a dependency between loop iterations. Order matters. In other cases though, the loop iterations are either entirely or partially independent. –Independence indicates that order of execution of the loop iterations isn’t important. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 17

Example Say we have a loop that runs through the rows in a 2D image, and performs a computation on each row that has no dependency on the state of any of the other rows. –Each row could be processed concurrently with the others. Dependence analysis of loops can get tricky when loops are nested. Dependencies may exist between outer loops, but not within inner loops. –Concurrency exists, but with limitations. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 18

Abstract types and data structures Languages also provide abstractions over the way data is represented in the machine. –Different types of numbers, strings, and structured types like records and objects. This is a big convenience both for managing memory and hiding data representations (e.g., how a complex number is stored). Data structures interact with concurrent code in interesting ways. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 19

Data structures Primitive types that are updated atomically at the machine level have few issues with concurrency since atomicity is guaranteed by hardware. Other types though do not have this hardware protection. –Arrays –Record types (e.g., C structs) –Objects © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 20

Data structures As we saw earlier in discussing monitors, there are mechanisms to protect complex data structures from concurrency bugs. Languages like Java provide language features like the synchronized keyword to protect data structures. Programmers frequently use explicit locks to protect data structures that are not protected at the language level. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 21

Functions and subroutines Finally, languages provide constructs for holding blocks of code. –Often to support parameterized reuse. –Functions often can be used to define the body of concurrently executing threads. Some languages allow functions to have types that indicate whether or not the function has side- effects. –This helps compilers and programmers reason about functions in concurrent environments. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 22

Outline Familiar language constructs Evaluating language constructs Interactions with concurrency © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 23

Evaluating language constructs A challenge for selecting language constructs, especially those that relate to concurrent programming, is selecting ones that make programming easier. Three criteria can be used to evaluate language constructs as proposed by Sebesta: –Readability –Writeability –Reliability © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 24

Readability A program really is a form of communication to: –The compiler, to generate a program that does what we want it to do. –Other programmers, who may need to work on the code independently. –Ourselves, since we often can’t keep all of the program logic in our heads for huge programs developed over long periods of time. Good language constructs make programs easy to read and understand the meaning of. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 25

Writeability Very closely tied to readability. A language should make it easy to express the logic of the problem being solved in code. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 26

Reliability Language constructs should have a well defined behavior in all situations. Type systems, error and exception handling systems all help towards this end. Features that ensure reliability can come at a cost of writeability by making code more verbose. –Example: requiring explicit type signatures instead of relying on dynamic runtime type checking. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 27

Cognitive dimensions Sebesta’s criteria are useful, but miss nuances that are very important in evaluating how language features are used by programmers. Green proposed a set of ‘cognitive dimensions’ that can be used to evaluate language constructs. These dimensions are very interesting with respect to concurrent programming. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 28

Cognitive Dimensions Viscosity: How much work is required to make a change? A language that has high viscosity resists changes by making it difficult to make them. –Example: having to edit many parts of the source code to rename a function. Visibility: How easily can the programmer see parts of the system? Data encapsulation methods can hinder visibility while enhancing protection. –Example: Hiding data in a monitor can increase robustness in concurrent setting, but can limit fine- grained performance tuning. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 29

Cognitive Dimensions Premature commitment: Forcing the programmer to make decisions before they have sufficient information to make them. Committing to a memory layout before knowing the number of threads that will share it is an example. Hidden dependencies: A language construct that is dependent on another without being explicitly stated is an example of this. This can occur in object hierarchies in which derived classes depend implicitly on a hidden property of a parent class. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 30

Cognitive Dimensions Role-expressiveness: This measures how clearly the role of an entity is in the code that uses it. –Example: an explicit semaphore type makes the role of a semaphore variable clearer than an integer used for the same purpose. Error proneness: Error prone constructs invite mistakes and rarely protect from them. –Example: C pointers are error prone. Java object references serve a similar purpose, but are less error prone since a well defined exception will be thrown that can be caught and dealt with. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 31

Cognitive Dimensions Abstraction: Abstractions make key features of a system explicit, while hiding less essential features. A language that encourages abstraction can be called abstraction rich, while languages that discourage it are abstraction poor. –Languages that force excessive use of abstractions can be challenging to use, and present programmers with an abstraction barrier. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 32

Cognitive Dimensions These are presented here to define a rigorous methodology that can be used when faced with a choice between languages. –Cognitive dimensions provide a concrete set of criteria for evaluating languages and their features. Given the explosion of languages with concurrency features over the last decade, this framework is valuable for making sense of how languages may compare with each other with an emphasis on programmer productivity. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 33

Outline Familiar language constructs Evaluating language constructs Interactions with concurrency © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 34

Implications of concurrency Languages are hard to design, even in sequential settings. Designers often seek what is known as orthogonality in their choice of language features. –Orthogonality means that the different features don’t interact with each other in unexpected or difficult ways. For example, the meaning of the while-loop language construct isn’t changed by the contents of the loop body in unexpected ways. While-loops are always while-loops. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 35

Implications of concurrency Concurrency often violates orthogonality goals. Example: A variable shared by multiple threads can lead to race conditions in assignment statements. –Different results depending on concurrent interactions. This makes assignment operators dependent on threading operations, violating traditional orthogonality assumptions. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 36

Implications of Concurrency Languages that integrate concurrency at the language level are far more likely to provide assurances of orthogonality between concurrency control primitives and other parts of the language. –Examples: Explicit guarantees of atomicity of expressions or statements Language-level blocking semantics for shared or locked data, where blocking behavior is part of the language instead of forced to be handled by the programmer. Most new languages are taking concurrency into account, as are revised standards for older ones. © 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 37