SPL/2010SPL/2010

Threads

1

SPL/2010SPL/2010

Today

● Processes and Scheduling● Threads● Abstract Object Models● Computation Models● Java Support for Threads

2

SPL/2010SPL/2010

Process vs. Program

● processes as the basic unit of execution● managed by OS ● OS as any RTE, executes processes● OS creates processes from programs, and

manages their resources

3

SPL/2010SPL/2010

Process resources

● To keep running, a process requires at least the following resources:● program (from which the process is created)● two blocks of memory: stack , heap ● resource tables: File handles, socket handles, IO

handles, window handles.● control attributes: Execution state, Process

relationship● processor state information: contents of

registers, Program Counter (PC), Stack Pointer

4

SPL/2010SPL/2010

Program context

● all the information the OS needs to keep track of the state of a process during its execution:– program counter

– registers

– memory associated with the process

● Register: very fast memory inside the CPU

5

SPL/2010SPL/2010

The Scheduler - OS component responsible for sharing the CPU

● OS run multiple processes simultaneously on a single CPU.

● OS interleaves the execution of the active processes:● runs a process a little while ● interrupts it and keeps its context in memory ● runs another process for a little while

6

Context switch

SPL/2010SPL/2010

Linux scheduler – task_struct

7

SPL/2010SPL/2010

Linux scheduler - main

8

SPL/2010SPL/2010

● UP(uni-processor) - single CPU system single process executing at given time

● SMP(symmetric multi processor) - several CPUs / cores in single CPU: number of processes concurrently execute

9

SPL/2010SPL/2010

Scheduler

● list of active processes - scheduler switch from one executing process to another

● Two interaction paradigms for scheduler with current active processes:● Non-Preemptive Scheduling● Preemptive Scheduling

10

SPL/2010SPL/2010

Non-preemptive scheduling

Non-Preemptive - process signals to OS when process is ready to relinquish the CPU:● special system call● process waits for an external event (I/O)● scheduler select next process to execute

according to a scheduling policy– pick the highest priority process

● Dos, Windows 3.1 , older versions of Mac OS. 

11

SPL/2010SPL/2010

Preemptive scheduling

Preemptive: scheduler interrupts executing process● interrupt issued using clock hardware:

– sends interrupt at regular intervals– suspends currently executing process– starts scheduler

● process passes control to OS: each time the process invokes a system call

● scheduler selects process to execute, according to the scheduling policy

● all modern OS support preemptive scheduling.

12

time slice: duration between two clock interrupts . time process execute un-interrupted

SPL/2010SPL/2010

Context Switch - OS switches between one executing process and

next one● consumes several milliseconds of

processing time (10^4 simple CPU operations).

● transparent to processes (process is not able to tell it was preempted)

13

SPL/2010SPL/2010

Context Switch - steps

● Timer interrupt – suspend currently executing process, start scheduler

● Save process context, for later resume● Select next process using scheduling policy● Retrieve next process context● Restore the state of the new process (registers , program

counter)● Flush CPU cache (process has new memory map, can not use

cache of old process)● Resume new process (start executing code from instruction

that was interrupted)

14

SPL/2010SPL/2010

Cache

● Accessing RAM memory is expensive ● compared to computation step on the CPU.

● CPU cache: frequently used memory addresses

● small very-fast memory section, on the CPU. ● a memory address copied in the CPU cache, can

be R/W as fast as computation on the CPU. ● context switch: CPU cache become invalid –

cache ``flushed'' - cells written back to actual RAM and cleared.

15

SPL/2010SPL/2010

The video player example

● The player should take the following steps in playing the video:● Read video from disk● Decompress video● Decode video ● Display on screen

● video is larger than actual RAM memory● video is watched before download

completes16

SPL/2010SPL/2010

Interleaving (sequential) solution

● Read some video data (disk /network)● Decompress● Decode ● Display on screen. ● Repeat until the video ends

- difficult to program correctly (modularity)- error prone - complexity explodes as concurrent activities

increase

17A B C D

SPL/2010SPL/2010

Multi-process solution

● playing the movie is decomposed into several independent tasks = processes:● read movie, decompress ,decode ,display

+ no need to control interleaving of tasks

- processes communication

18

SPL/2010SPL/2010

Threads - definition

● single process, multiple tasks simultaneous (no communication, no context switch…)● multiple threads executing concurrently● share all the resources allocated to process● communicate with each other using constructs

which are built in most modern languages● share memory space / each thread own stack● share opened files and access rights

19

SPL/2010SPL/2010

Low cost context switch between threads

● not all steps of a regular context switch need to be taken:● no need to restore context (share resources)● no need to flush the CPU cache (share

memory)● switch stacks

20

SPL/2010SPL/2010

multi-threaded solution - concurrency

● single process, several threads design:● thread reads video stream and place chunks

in chunk queue. ● thread reads chunks from queue, decompress

and place in decompressed queue. ● thread decodes into frames and queues in

frame queue… ● final thread takes frame and displays on

screen.

21

SPL/2010SPL/2010

Concurrency advantages

Liberate from invoking method and blocking, while waiting for reply

● Reactive programming: programs do multiple things at a time, reactive response to input ● video player, GUI…

22

SPL/2010SPL/2010

Concurrency advantages

● Availability: common design pattern for service provider programs: ● thread as gateway for incoming service

consumers ● thread for handling requests

● FTP server: gateway thread to handle new clients connecting, thread (per client) to deal with long file transfers.

23

SPL/2010SPL/2010

Concurrency advantages

● Controllability: thread can be suspended, resumed or stopped by another thread

● Simplified design: Software objects usually model real objects... ● real life objects are independent and parallel. ● designing autonomous behavior is easier

than sequential (interleaving between objects)

● Simplified implementation than processes

24

SPL/2010SPL/2010

Concurrency advantages

● Parallelization: ● on multiprocessor machines, threads

executes truly concurrently allowing one thread per CPU.

● on single CPU, execution paths are interleaved

● services provided by RTE operate in a concurrent manner

25

SPL/2010SPL/2010 26

SPL/2010SPL/2010

Concurrency limitations - resource consumption, efficiency and program

complexity● Safety: multiple threads share resources

-need for synchronization mechanisms ● guarantee consistent state vs. random

looking, inconsistencies, real-time debugging● Liveness: keeping a thread alive in

concurrent programming ● Non determinism: executions of

concurrent program are not identical - harder to predict understand and debug.

27

SPL/2010SPL/2010

Concurrency limitations - resource consumption, efficiency and program

complexity● Context switching overhead: when a job

performed in a thread is small● Request/Reply programming: threads are

not a good choice in sequential tasks ● synchronizing costs and introduce complexity

● Synchronization overhead: execution time and complexity

● Process: when activity is self contained and heavy - encapsulate in a different standalone program. Can be accessed via system services

28

SPL/2010SPL/2010

Abstract Object Models

● programming issues related to threads● formal model of concurrent objects● can be implemented in different RTEs or

programming languages. ● abstract model -> implementation in Java

29

SPL/2010SPL/2010 30

SPL/2010SPL/2010 31

SPL/2010SPL/2010

represent/simulate a water tank

● Attributes: capacity, currentVolume, represented as fields of WaterTank objects

● Invariant state constraints: currentVolume always remains between zero and capacity

● Operations describing behaviors such as those to addWater and removeWater.

● Connections to other objects● Preconditions and postconditions on the effects

of operations● Protocols constraining when and how messages

(operation requests) are processed.32

SPL/2010SPL/2010

Object models framework

● structure of object:● class● internal attributes - state● connections to other objects ● local internal methods ● messaging methods - interface

33

in Java, sending a message to an object is just calling one of the object's public methods

SPL/2010SPL/2010

Object models framework

● Object identity: ● objects are constructed any time (resources!) ● by any object (access control!)● object maintains unique identity

● Encapsulation:● separation between inside and outside parts -

internal state can be modified only by object(assuming internal members are private)

34

SPL/2010SPL/2010

Object models framework

● Communication between objects ● message passing ● objects issue messages - trigger actions in

other● simple procedural calls/communication

protocols.● Connections:

● send message by identity/ by communication channel identities

35

SPL/2010SPL/2010

Object models framework

● Objects can perform only the following operations:● Accept a message● Update their internal state● Send a message● Create a new object

36

SPL/2010SPL/2010

computation models: sequential mappings

37

SPL/2010SPL/2010

computation models: sequential mappings

general-purpose computer can be exploited to pretend it is any object:

● loading description of corresponding .class into VM

● VM construct passive representation of instance ● VM interpret associated operations. ● extends to programs involving many objects of

different classes ● VM is itself an object - can pretend it is any other

object38

SPL/2010SPL/2010

● On a sequential JVM - impossible to simulate concurrent interacting waterTank objects

● message-passing is sequential - there is no need for concurrent processing

39

SPL/2010SPL/2010

active objects (actor models)

● every object is autonomous and powerful as a sequential VM.

● objects reside on different machines● message passing is performed via remote

communication. ● object-oriented view of OS-level

processes: ● process is independent of, and shares as few

as possible resources with other processes.40

SPL/2010SPL/2010 41

SPL/2010SPL/2010

active objects

● different objects may reside on different machines

● location and administrative domain of an object are often important

● message passing is arranged via remote communication (for example via sockets)

● number of protocols: oneway messaging multicasts procedure-style request-reply

42

SPL/2010SPL/2010

active objects

● agents programming paradigm:

43

SPL/2010SPL/2010

active objects

● The active object design pattern decouples method execution from method invocation

● introduce concurrency, by using asynchronous method invocation and scheduler for requests

● pattern consists of six elements:

1. proxy - interface towards clients with publicly accessible methods.

2. interface defines the method request on an active object.

3. list of pending requests from clients

4. scheduler, which decides which request to execute next

5. implementation of the active object method.

6. callback or variable for the client to receive the result.44

SPL/2010SPL/2010 45

SPL/2010SPL/2010

Mixed models - multithreading

● between the two extremes of passive and active models.

● concurrent VM may be composed of multiple threads of execution

● each thread acts in about the same way as a single sequential VM

● all threads share access to the same set of passive representations (unlike pure active objects )

46

SPL/2010SPL/2010

Mixed models

● can simulate the first two models, but not vice versa.

● passive sequential models can be programmed using only one thread.

● active models can be programmed by creating as many threads as there are active objects, ● !!!avoiding situations in which more than one thread

can access a given passive representation

47

SPL/2010SPL/2010

Thread-based concurrent object oriented models

● separate passive from active objects. ● passive objects show thread-awareness

(locks)

48

SPL/2010SPL/2010

Java Support for Threads● JVM implements the mixed object model

(until now, you have been using only passive object)

● Runnable interface - implemented by class whose instances are intended to be executed by a thread● define a method run()

49

SPL/2010SPL/2010 50

class MessagePrintermethod run() - when invoked, the object prints a message which it received in constructor

main:

SPL/2010SPL/2010

SequentialPrinter in JVM

● loads SequentialPrinter class● calls main() function● impersonates class SequentialPrinter● creates two objects of MessagePrinter with unique id● MessagePrinter object reachable via mpHello is sent a

message to run().● MessagePrinter object reachable via mpGoodbye is

sent a message to run()● Result: two words printed, one after the other. "Hello“

"Goodbye"

51

SPL/2010SPL/2010

ConcurrentPrinter in JVM

● mixed mode object model - multithreaded version, using threads for MessagePrinters

52

SPL/2010SPL/2010

ConcurrentPrinter in JVM● loads ConcurrentPrinter class ● calls the main() function. ● impersonates the class ConcurrentPrinter● creates two objects of MessagePrinter with unique id ● instantiate two new special, active objects (threads…)● each thread receives as an argument a Runnable object, r. ● When thread is given the message to start, it will then

send a message to r ● each thread impersonates r and invokes r's run() method● last thing JVM does as ConcurrentPrinter is send both of the threads

the start() message.● two separate threads, each invoking the run() method of a

different MessagePrinter object - we cannot know ahead of time printed order

53