Living with Concurrency Peter Grogono Computer Science and - - PowerPoint PPT Presentation

▶
living with concurrency
SMART_READER_LITE
LIVE PREVIEW

Living with Concurrency Peter Grogono Computer Science and - - PowerPoint PPT Presentation

Oct 22, 2022 222 likes •873 views

Living with Concurrency Peter Grogono Computer Science and Software Engineering Concordia University CUSEC 18 January 2008 Bob Dewar & Ed Schonberg Computer Science Education: Where Are the Software Engineers of Tomorrow?

slide-1
SLIDE 1

Living with Concurrency

Peter Grogono

Computer Science and Software Engineering Concordia University CUSEC 18 January 2008

slide-2
SLIDE 2

Bob Dewar & Ed Schonberg

Computer Science Education: Where Are the Software Engineers of Tomorrow? http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html

Mathematics requirements in CS programs are shrinking. The development of programming skills in several languages is giving way to cookbook approaches using large libraries and special-purpose packages. The resulting set of skills is insufficient for today’s software industry. . . They quote. . .

CUSEC 2008 1/40

slide-3
SLIDE 3

Bjarne Stroustrup

"I have had a lot of complaints about [the use of Java as a first programming language] from industry, specifically from AT&T, IBM, Intel, Bloomberg, NI, Microsoft, Lockheed-Martin, and more. "[Texas A&M] did [teach Java as the first language]. Then I started teaching C++ to the electrical engineers and when the EE students started to out-program the CS students, the CS department switched to C++."

CUSEC 2008 2/40

slide-4
SLIDE 4

At [XYZU], our [assembler and C++] students acquire and refine analytical and communications skills that make them better able to approach any problem creatively and successfully; the study habits and work ethic they develop are those needed for success in demanding graduate and professional programs and in real-world careers.

CUSEC 2008 3/40

slide-5
SLIDE 5

EDSAC II

CUSEC 2008 4/40

slide-6
SLIDE 6

Maurice Wilkes

CUSEC 2008 5/40

slide-7
SLIDE 7

Maurice Wilkes

CUSEC 2008 5a/40

slide-8
SLIDE 8

Maurice Wilkes

"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. "Debugging had to be discovered. "I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

CUSEC 2008 5b/40

slide-9
SLIDE 9

Java as the first language. . .

The good news is that students learn to

  • program without distractions
  • use libraries, packages, . . .
  • enjoy programming (pretty results)

The bad news is that students

  • don't use algorithms
  • are scared of pointers
  • don't appreciate costs

CUSEC 2008 6/40

slide-10
SLIDE 10

"A cynic is a man who knows the price of everything but the value of nothing." Oscar Wilde (1854-1900) "A LISP programmer knows the value of everything, but the cost of nothing." Alan Perlis (1922-1990)

CUSEC 2008 7/40

slide-11
SLIDE 11

default (Integer,Rational,Float) infixr 9 # series f = f : repeat 0 instance Num a => Num [a] where fromInteger c = series(fromInteger c) negate (f:ft) = -f : -ft (f:ft) + (g:gt) = f+g : ft+gt (f:ft) * gs@(g:gt) = f*g : ft*gs + series(f)*gt instance Fractional a => Fractional [a] where (f:ft) / (g:gt) = qs where qs = f/g : series(1/g)*(ft-qs*gt) (f:ft) # gs@(0:gt) = f : gt*(ft#gs) revert (0:ft) = rs where rs = 0 : 1/(ft#rs) integral fs = 0 : zipWith (/) fs [1..] derivative (_:ft) = zipWith (*) ft [1..]

(Doug McIlroy, 1998)

CUSEC 2008 8/40

slide-12
SLIDE 12

dy dx = y y(0) = 1 y = 1 +

x

0 y(t) dt

expx = 1 + (integral expx) [ 1/1, 1/1, 1/2, 1/6, 1/6, 1/24, 1/720, ... ]

CUSEC 2008 9/40

slide-13
SLIDE 13

d dx sin x = cos x sin 0 = 0 d dx cos x = − sin x cos 0 = 1 sinx = integral cosx cosx = 1 - (integral sinx) [ 1/1, -1/6, 1/120, -1/5040, ... ] [ 1/1, -1/2, 1/24, -1/720, ... ]

CUSEC 2008 10/40

slide-14
SLIDE 14

"I would like to see components become a dignified branch of software engineering." (Doug McIlroy, 1968)

CUSEC 2008 11/40

slide-15
SLIDE 15

Language is not the issue!

You should be able to think with:

  • bjects

C#, C++, Eiffel, Java, Smalltalk, . . .

functions

LISP, Scheme, ML, Haskell, . . .

data

lists, trees, graphs, maps, . . . , and corresponding algorithms

hardware

registers, caches, addresses, pointers, . . .

concurrency

processes, threads, semaphores, monitors, . . .

CUSEC 2008 12/40

slide-16
SLIDE 16

You have to know lots of other things too, of course,. . .

"soft" skills project management collaborative work software development processes applications . . .

CUSEC 2008 13/40

slide-17
SLIDE 17

Why Concurrency?

CUSEC 2008 14/40

slide-18
SLIDE 18

Why Concurrency?

[Dr. Dobbs Journal, 3/2005]

CUSEC 2008 14a/40

slide-19
SLIDE 19

Why Concurrency?

CUSEC 2008 14b/40

slide-20
SLIDE 20

Why Concurrency?

SPE = SIMD Synergistic Processor Element

CUSEC 2008 14c/40

slide-21
SLIDE 21

Problem: Concurrent programming is hard !

deadlock, livelock, starvation, race conditions, mamihlapinatapai, . . .

CUSEC 2008 15/40

slide-22
SLIDE 22

Presentation Business Logic Data

CUSEC 2008 15a/40

slide-23
SLIDE 23

Presentation Business Logic ⇐ concurrency Data

CUSEC 2008 15b/40

slide-24
SLIDE 24

The development of business applications using OO middleware has reached unparalleled complexity. In spite of greatly improved tools and development practices, more and more of the IT budget is wasted in maintenance rather than adding business value. Dave Thomas (2008)

CUSEC 2008 16/40

slide-25
SLIDE 25

We must and can build concurrent computation models that are far more deterministic, and we must judiciously and carefully introduce nondeterminism where needed. Nondeterminism should be explicitly added to programs, and only where needed, as it is in sequential

  • programming. Threads take the
  • pposite approach. They make

programs absurdly nondeterministic and rely on programming style to constrain that nondeterminism to achieve deterministic aims. Edward Lee (2006)

CUSEC 2008 17/40

slide-26
SLIDE 26

Requirements Specification Design PL machine code

CUSEC 2008 18/40

slide-27
SLIDE 27

Change moves upwards in the funnel:

spaghetti

??

− →

waterfall structured code −

→

SADT

Structured Analysis & Design Technique

  • bject-oriented languages −

→

OOAD

Object-Oriented Analysis & Design

aspect-oriented languages −

→

AOSD

Aspect-Oriented Software Development

CUSEC 2008 19/40

slide-28
SLIDE 28

Therefore: To effect change in the software development process, we must change the programming paradigm.

CUSEC 2008 20/40

slide-29
SLIDE 29

Change moves upwards in the funnel:

spaghetti

??

− →

waterfall structured code −

→

SADT

Structured Analysis & Design Technique

  • bject-oriented languages −

→

OOAD

Object-Oriented Analysis & Design

aspect-oriented languages −

→

AOSD

Aspect-Oriented Software Development

process-oriented languages

??

− →

POMDD

Process-Oriented Model-Driven Design

CUSEC 2008 21/40

slide-30
SLIDE 30

Hypothesis

POMDD will succeed because: real world ∼ = concurrent processes concurrent processes ⇒ multiprocessors multiprocessors ⇒ concurrent software concurrent software ⇒ models real world cells/processes ⇒ lower coupling lower coupling ⇒ refactoring experience (1970s) ⇒ we can do it !

CUSEC 2008 22/40

slide-31
SLIDE 31

The Erasmus Project

Desiderius Erasmus of Rotterdam (1466-1536)

CUSEC 2008 23/40

slide-32
SLIDE 32

The Erasmus Project

CUSEC 2008 23a/40

slide-33
SLIDE 33

Main

Cell

Main = (); Main();

CUSEC 2008 24/40

slide-34
SLIDE 34

serverProc

Process

clientCell Main prot prot = [ ]; serverProc = { p +: prot | }; clientCell = ( p -: prot | ); Main = ( p :: prot; serverProc(p); clientCell(p) ); Main();

CUSEC 2008 24a/40

slide-35
SLIDE 35

prot = [ start; *( query: Text; ^reply: Integer ); stop ]; serverProc = { p +: prot | p.start; loopselect || input: Text := p.query; p.reply := 0 || p.stop; exit end }; clientCell = ( p -: prot | ); Main = ( p :: prot; serverProc(p); clientCell(p) ); Main();

CUSEC 2008 25/40

slide-36
SLIDE 36

serverProc clientCell clientProcess Main prot clientProc = { p -: prot | }; clientCell = ( p -: prot | clientProc(p) );

CUSEC 2008 26/40

slide-37
SLIDE 37

Protocols

query = [ question; ^answer ] sequence = [ first: Integer; second: Text; third: Float ] method1 = [ *( arg1; arg2; ...; ^result ) ] method2 = [ *( arg1; arg2; ...; ^res1; ^res2 ) ] class = [ *( M1 | M2 | ... | Mn ) ]

CUSEC 2008 27/40

slide-38
SLIDE 38

Statements

select || p.red; ... || p.yellow; ... || p.green; ... end select |stored < 10| buff[i] := p.x; ... |stored > 0| q.y := buff[j]; ... end select fair ... select ordered ... select random ...

CUSEC 2008 28/40

slide-39
SLIDE 39

Processes

prot = [ *( arg: Integer ) ]; filter = { p +: prot | prime: Integer := p.arg; sys.out := text prime + ’ ’; q -: prot; filter(q); loop n: Integer := p.arg; if n % prime != 0 then q.arg := n end end };

CUSEC 2008 29/40

slide-40
SLIDE 40

filter p q filter p q filter p q filter p q filter p q filter p q filter pq filter pq filter p q filter p q filter p q filter p q

CUSEC 2008 30/40

slide-41
SLIDE 41

filter

CUSEC 2008 30a/40

slide-42
SLIDE 42

Semantics vs. Deployment

square squareCell client clientCell main p p ch

CUSEC 2008 31/40

slide-43
SLIDE 43

Code

sqProt = [ *( query: Float; ^reply: Text ) ]; square = { p +: sqProt | loop q: Float := p.query; p.reply := text(q * q); end }; squareCell = ( port +: sqProt | square(port) ); client = { p -: sqProt | p.query := 2; sys.out := p.reply + "\n"; }; clientCell = ( port -: sqProt | client(port) ); main = ( ch :: sqProt; squareCell(ch); clientCell(ch) ); main();

CUSEC 2008 31a/40

slide-44
SLIDE 44

Metacode

<Mapping> <Processor> alpha.encs.concordia.ca <Port> 5555 </Port> <Cell> squareCell </Cell> <Cell> clientCell1 </Cell> </Processor> <Processor> beta.encs.concordia.ca <Port> 5555 </Port> <Cell> squareCell1 </Cell> <Cell> clientCell </Cell> </Processor> </Mapping>

CUSEC 2008 31b/40

slide-45
SLIDE 45

Cells

Programs consist of cells Cells may contain variables, processes, and cells Cells can be of any size

programs are ``fractal''

Cells are ``first-class citizens'' Control flow never crosses a cell boundary Cells are explicitly provided with all needed resources Cells may exchange messages Processes within a cell behave as co-routines

CUSEC 2008 32/40

slide-46
SLIDE 46

Processes

A process is always inside a cell Processes may contain variables, processes, and cells Processes are ``first-class citizens'' All actions are performed within processes Control flow never crosses a process boundary A process may access variables within its cell Processes communicate by exchanging messages A process relinquishes control when it communicates

no race conditions

CUSEC 2008 33/40

slide-47
SLIDE 47

C1 # C2 # P1 P2 P3 V1 V2

One program counter per cell

CUSEC 2008 34/40

slide-48
SLIDE 48

Protocols

Protocols define interfaces Protocols specify communication patterns Protocols consist of typed messages and signals Protocols define sequence, choice, and repetition There is a ``satisfaction'' relation on protocols

CUSEC 2008 35/40

slide-49
SLIDE 49

Messages

A ``sent'' message is an lvalue: p.result := 42; A ``received'' message is an rvalue: sum := p.val + ...; Signals synchronize: p.stop

CUSEC 2008 36/40

slide-50
SLIDE 50

Messages

A ``sent'' message is an lvalue: p.result := 42; A ``received'' message is an rvalue: sum := p.val + q.val; Signals synchronize: p.stop

CUSEC 2008 36a/40

slide-51
SLIDE 51

Separation of Concern

Cells define structure

∼

Processes define action Code defines meanings

∼

Metacode defines deployment Protocols specify processes

∼

Protocols ensure satisfaction

CUSEC 2008 37/40

slide-52
SLIDE 52

The case against

CUSEC 2008 38/40

slide-53
SLIDE 53

The case against

It's been tried before

(CSP, occam, Joyce, Amber, Erlang, Hermes, . . . )

CUSEC 2008 38a/40

slide-54
SLIDE 54

The case against

It's been tried before

(CSP, occam, Joyce, Amber, Erlang, Hermes, . . . )

Programming languages are not the problem

CUSEC 2008 38b/40

slide-55
SLIDE 55

The case against

It's been tried before

(CSP, occam, Joyce, Amber, Erlang, Hermes, . . . )

Programming languages are not the problem Object-oriented programming is good enough

CUSEC 2008 38c/40

slide-56
SLIDE 56

The case against

It's been tried before

(CSP, occam, Joyce, Amber, Erlang, Hermes, . . . )

Programming languages are not the problem Aspect-oriented programming is good enough

CUSEC 2008 38d/40

slide-57
SLIDE 57

The case against

It's been tried before

(CSP, occam, Joyce, Amber, Erlang, Hermes, . . . )

Programming languages are not the problem Aspect-oriented programming is good enough We've hidden the hard bits

3-tier: CICS, J2EE, CORBA, ...

CUSEC 2008 38e/40

slide-58
SLIDE 58

The case against

It's been tried before

(CSP, occam, Joyce, Amber, Erlang, Hermes, . . . )

Programming languages are not the problem Aspect-oriented programming is good enough We've hidden the hard bits

3-tier: CICS, J2EE, CORBA, ...

Introducing a new paradigm is no longer feasible

CUSEC 2008 38f/40

slide-59
SLIDE 59

The case for

CUSEC 2008 39/40

slide-60
SLIDE 60

The case for

Many distributed applications

CUSEC 2008 39a/40

slide-61
SLIDE 61

The case for

Many distributed applications Multicore processors

CUSEC 2008 39b/40

slide-62
SLIDE 62

The case for

Many distributed applications Multicore processors Process-oriented programming is ... good

CUSEC 2008 39c/40

slide-63
SLIDE 63

The case for

Many distributed applications Multicore processors Process-oriented programming is ... good

We need software

                                          

development maintenance growth adaptation evolution refactoring

CUSEC 2008 39d/40

slide-64
SLIDE 64

The End

</Keynote>

CUSEC 2008 40/40