Embed Size (px)
Citation preview
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:
● a 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 process 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
Preemptive/Non-preemptive scheduling
● UP(uni-processor) - single CPU systemsingle process executing at given time
● SMP(symmetric multi processor) - several CPUs / cores in single CPU: number of processes concurrently execute
● list of active processes - scheduler switch from one executing process to another
9
SPL/2010SPL/2010
Preemptive/Non-preemptive scheduling
● Two interaction paradigms for scheduler with current active processes:
● Non-Preemptive Scheduling
● Preemptive Scheduling
10
SPL/2010SPL/2010
Preemptive/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/Non-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 and display on screen
● video is larger than actual RAM memory
● video is watched before download completes
16
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
● one process, multiple tasks simultaneous (no communication, no context switch…)
● single process, 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
● same 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
● 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…
● 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.
22
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
23
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
24
SPL/2010SPL/2010 25
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.
26
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 when 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
27
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
28
SPL/2010SPL/2010 29
SPL/2010SPL/2010 30
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.
31
SPL/2010SPL/2010
Object models framework
● structure of object:
● class
● internal attributes - state
● connections to other objects
● local internal methods
● messaging methods - interface
32
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)
33
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
34
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
35
SPL/2010SPL/2010
computation models: sequential mappings
36
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 object
37
SPL/2010SPL/2010
● On a sequential JVM - impossible to simulate concurrent interacting waterTank objects
● message-passing is sequential procedural invocation - there is no need for concurrent processing
38
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.
39
SPL/2010SPL/2010 40
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.
41
SPL/2010SPL/2010 42
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
43
SPL/2010SPL/2010
computation models: active objects
● agents programming paradigm:
44
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 )
● can simulate the first two models, but not vice versa.
45
SPL/2010SPL/2010
● 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
46
SPL/2010SPL/2010
Thread-based concurrent object oriented models
● separate passive from active objects.
● passive objects show thread-awareness (locks)
47
SPL/2010SPL/2010
Java Support for Threads
● JVM implements the mixed object model (until now, you have been using only passive object)
● class MessagePrinter
● method run() - when invoked, the object prints a message which it received in constructor
48
SPL/2010SPL/2010 49
class MessagePrinter:
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"
50
SPL/2010SPL/2010
ConcurrentPrinter in JVM
● mixed mode object model - multithreaded version, using threads for MessagePrinters
51
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
52
