Скачать презентацию Processes Chapter 3 1 Processes p p Скачать презентацию Processes Chapter 3 1 Processes p p

1633dc0a5019ffc2bfbab9025c103fc2.ppt

  • Количество слайдов: 50

Processes Chapter 3 1 Processes Chapter 3 1

Processes p p p Communication takes place between processes. But, what’s a process? “A Processes p p p Communication takes place between processes. But, what’s a process? “A program in execution” Traditional operating systems: concerned with the “local” management and scheduling of processes. Modern distributed systems: a number of other issues are of equal importance. There are three main areas of study: 1. 2. 3. Threads (within clients/servers). Process and code migration. Software agents. 2

Introduction to Threads Modern OSes provide “virtual processors” within which programs execute. p A Introduction to Threads Modern OSes provide “virtual processors” within which programs execute. p A programs execution environment is documentated in the process table and assigned a PID. p p To achieve acceptable performance in distributed systems, relying on the OS’s idea of a process is often not enough - finer granularity is required. p The solution: Threading. 3

Threads p Process n n p Process table n p Entries to CPU register Threads p Process n n p Process table n p Entries to CPU register values, memory maps, open files, accounting infor. , privileges, etc. Cost highly n n n p A program in execution, or A program is currently being executed on one of the OS’s virtual processors. Saving CPU context, e. g. , register values, program counter, stack pointers, etc. Modify registers of the memory management unit (MMU) Invalidate address translation caches such as in the translation lookaside buffer (TLB) Swapping processes Occupies main memory simultaneously Thread n Thread context consists of nothing more than the CPU context. 4

Benefits of Threads p A single-thread process n n p The process as a Benefits of Threads p A single-thread process n n p The process as a whole is blocked whenever a blocking system call is executed. For example, a spreadsheet program Multithreading n n Becomes possible to exploit parallelism Useful in the context of large applications p p p One application, several cooperating programs, each to be executed by a separate process. Interprocess communication (IPC) is needed if cooperating programs are implemented. When IPC is invoked, it requires changing the memory map in the MMU, as well as flushing the TLB. 5

Two Important Implications 1. Threaded applications often run faster than nonthreaded applications (as context-switches Two Important Implications 1. Threaded applications often run faster than nonthreaded applications (as context-switches between kernel and user-space are avoided). 2. Threaded applications are harder to develop (although simple, clean designs can help here). 3. Additionally, the assumption is that the development environment provides a Threads Library for developers to use (most modern environments do). 6

Thread Implementation p Tow approaches to implement a thread package n n p To Thread Implementation p Tow approaches to implement a thread package n n p To construct a thread library that is executed entirely in user mode To have the kernel be aware of threads and schedule them User-level thread n n n Easy to create and destroy Creating a thread is primarily determined by the cost for allocating memory to set up a thread stack. Destroying a thread involves freeing memory for the stack. Switching thread context can be done in a few instructions. Drawbacks: p Encounter a blocking system call (e. g. , I/O) 7

Threads in Non-Distributed Systems p Advantages: 1. Blocking can be avoided Excellent support for Threads in Non-Distributed Systems p Advantages: 1. Blocking can be avoided Excellent support for multi-processor systems (each running their own thread). Expensive context-switches can be avoided. For certain classes of application, the design and implementation is made considerably easier. 2. 3. 4. 8

Threads in Distributed Systems p Important characteristic: a blocking call in a thread does Threads in Distributed Systems p Important characteristic: a blocking call in a thread does not result in the entire process being blocked. p The leads to the key characteristic of threads within distributed systems: n “We can now express communications in the form of maintaining multiple logical connections at the same time (as opposed to a single, sequential, blocking process). ” 9

Example: MT Clients and Servers p Mutli-Threaded Client: to achieve acceptable levels of perceived Example: MT Clients and Servers p Mutli-Threaded Client: to achieve acceptable levels of perceived performance, it is often necessary to hide communications latencies. p Consequently, a requirement exists to start communications while doing something else. p Example: modern web browsers. p This leads to the notion of “truly parallel streams of data” arriving at a multi-threaded client application. 10

Example: MT-Servers p Although threading is useful on clients, it is much more useful Example: MT-Servers p Although threading is useful on clients, it is much more useful in distributed systems servers. p The main idea is to exploit parallelism to attain high performance. p A typical design is to organize the server as a single “dispatcher” with multiple threaded “workers”, as diagrammed overleaf. 11

Multi-Threaded Servers (1) p A multithreaded server organized in a dispatcher/worker model. 12 Multi-Threaded Servers (1) p A multithreaded server organized in a dispatcher/worker model. 12

Multi-Threaded Servers (2) Model Characteristics Threads Parallelism, blocking system calls Single-threaded process No parallelism, Multi-Threaded Servers (2) Model Characteristics Threads Parallelism, blocking system calls Single-threaded process No parallelism, blocking system calls Finite-state machine Parallelism, nonblocking system calls hard to implement p Three ways to construct a server. 13

More on Clients and Servers p What’s a client? p Definition: “A program which More on Clients and Servers p What’s a client? p Definition: “A program which interacts with a human user and a remote server. ” p Typically, the user interacts with the client via a GUI. p Of course, there’s more to clients than simply providing a UI. Remember the multitiered levels of the Client/Server architecture from earlier … 14

Multi-Tiered Client Architectures 15 Multi-Tiered Client Architectures 15

The X-Window System p The basic organization of the X Window System 16 The X-Window System p The basic organization of the X Window System 16

Client-Side Software for Distribution Transparency p A possible approach to transparent replication of a Client-Side Software for Distribution Transparency p A possible approach to transparent replication of a remote object using a client-side solution. 17

What’s a Server? p Definition: “A process that implements a specific service on behalf What’s a Server? p Definition: “A process that implements a specific service on behalf of a collection of clients”. p Typically, servers are organized to do one of two things: 1. 2. Wait Service … wait … service … wait … 18

Servers: Iterative and Concurrent p Iterative: server handles request, then returns results to the Servers: Iterative and Concurrent p Iterative: server handles request, then returns results to the client; any new client requests must wait for previous request to complete (also useful to think of this type of server as sequential). p Concurrent: server does not handle the request itself; a separate thread or subprocess handles the request and returns any results to the client; the server is then free to immediately service the next client (i. e. , there’s no waiting, as service requests are processed in parallel). 19

Problem: Identifying “end-points”? How do clients know which end-point (or port) to contact a Problem: Identifying “end-points”? How do clients know which end-point (or port) to contact a server at? How do they “bind” to a server? p Statically assigned end-points (IANA, Internet Assigned Numbers Authority). p n n p FTP, TCP port 21 HTTP, TCP port 80. Dynamically assigned end-points (DCE). A popular variation: p the “super-server” (inetd on UNIX). p 20

Servers: General Design Issues a) b) Client-to-server binding using a daemon (DCE) Client-to-server binding Servers: General Design Issues a) b) Client-to-server binding using a daemon (DCE) Client-to-server binding using a super-server (inetd on UNIX) 3. 7 21

Server “States” p Stateless servers – no information is maintained on the current “connections” Server “States” p Stateless servers – no information is maintained on the current “connections” to the server. The web is the classic example of a stateless service. As can be imagined, this type of server is easy to implement. p Stateful servers – information is maintained on the current “connections” to the server. Advanced file servers, where copies of a file can be updated “locally” then applied to the main server (as the server knows the state of things). These are more difficult to implement. p But, what happens if something crashes? (More on this later, see chapter 7). p 22

A Special Type: Object Servers p A server tailored to support distributed objects. Does A Special Type: Object Servers p A server tailored to support distributed objects. Does not provide a specific service. p Provides a facility whereby objects can be remotely invoked by non-local clients. p p Consequently, object servers are highly adaptable. p “A place where objects live”. 23

Code Migration p Under certain circumstances, in addition to the usual passing of data, Code Migration p Under certain circumstances, in addition to the usual passing of data, passing code (even while it is executing) can greatly simplify the design of a distributed system. p However, code migration can be inefficient and very costly. p So, why migrate code? 24

Reasons for Migrating Code p Why? p Biggest single reason: better performance. p The Reasons for Migrating Code p Why? p Biggest single reason: better performance. p The big idea is to move a computeintensive task from a heavily loaded machine to a lightly loaded machine “on demand” and “as required”. 25

Code Migration Examples p Moving (part of) a client to a server – processing Code Migration Examples p Moving (part of) a client to a server – processing data close to where the data resides. It is often too expensive to transport an entire database to a client for processing, so move the client to the data. p Moving (part of) a server to a client – checking data prior to submitting it to a server. The use of local error-checking (with Java. Script) on web forms is a good example of this type of processing. Error-check the data close to the user, not at the server. 26

“Classic” Code Migration Example p Searching the web by “roaming”. p Rather than search “Classic” Code Migration Example p Searching the web by “roaming”. p Rather than search and index the web by requesting the transfer of each and every document to the client for processing, the client relocates to each site and indexes the documents it finds “in situ”. The index is then transported from site to site, in addition to the executing process. 27

Reasons for Migrating Code p The principle of dynamically configuring a client to communicate Reasons for Migrating Code p The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server. 28

Major Disadvantage p Security Concerns. p “Blindly trusting that the downloaded code implements only Major Disadvantage p Security Concerns. p “Blindly trusting that the downloaded code implements only the advertised interface while accessing your unprotected hard-disk and does not send the juiciest parts to heaven-knows-where may not always be such a good idea”. 29

Code Migration Models p A running process consists of three “segments”: n Code Segment Code Migration Models p A running process consists of three “segments”: n Code Segment – instructions p n Resource Segment – external references. p n The part that contains the set of instructions that make up the program that is being executed. The part that contains references to external resources needed by the process, such as files, printers, devices, other processes, and so on. Execution Segment – current state. p Used to store the current execution state of a process, consisting of private data, the stack, and the program counter. 30

Code Migration Characteristics Weak Mobility: just the code is moved – and it always Code Migration Characteristics Weak Mobility: just the code is moved – and it always restarts from its initial state. p e. g. Java Applets. p Comment: simplementation, but limited applicability. p Strong Mobility: the code and the state is moved – and execution restarts from the next statement. p e. g. D’Agents. p Comment: very powerful, but hard to implement. p 31

More Characteristics p Sender- vs. Receiver-Initiated. p Which side of the communication starts the More Characteristics p Sender- vs. Receiver-Initiated. p Which side of the communication starts the migration? The machine currently executing the code (known as sender-initiated), or p The machine that will ultimately execute the code (known as receiver-initiated). p 32

How Does the Migrated Code Run? p Another issue surrounds where the migrated code How Does the Migrated Code Run? p Another issue surrounds where the migrated code executes: - Within an existing process (possibly as a thread) or Within it’s own (new) process space. - Finally, strong mobility also supports the notion of “remote cloning”: an exact copy of the original process, but now running on a different machine. 33

Models for Code Migration p Alternatives for code migration. 34 Models for Code Migration p Alternatives for code migration. 34

What About Resources? p This is tricky. p What makes code migration difficult is What About Resources? p This is tricky. p What makes code migration difficult is the requirement to migrate resources. p Resources are the external references that a process is currently using, and includes (but is not limited to): p Variables, open files, network connections, printers, databases, etc. 35

Types of Process-to-Resource Binding p Strongest: binding-by-identifier (BI) – precisely the referenced resource, and Types of Process-to-Resource Binding p Strongest: binding-by-identifier (BI) – precisely the referenced resource, and nothing else, has to be migrated. p Binding-by-value (BV) – weaker than BI, but only the value of the resource need be migrated. p Weakest: binding-by-type (BT) – nothing is migrated, but a resource of a specific type needs to be available after migration (eg, a printer). 36

More Resource Classification p Resources are further distinguished as one of: 1. 2. 3. More Resource Classification p Resources are further distinguished as one of: 1. 2. 3. p Unattached: a resource that can be moved easily from machine to machine. Fastened: migration is possible, but at a high cost. Fixed: a resource is bound to a specific machine or environment, and cannot be migrated. Refer to diagram 3 -14 in the textbook for a good summary of resource-to-binding characteristics (to find out what to do with which resource when). 37

Migration and Local Resources Resource-to machine binding Unattached Process-to- By identifier resource By value Migration and Local Resources Resource-to machine binding Unattached Process-to- By identifier resource By value binding By type p Fastened Fixed MV (or GR) CP ( or MV, GR) RB (or GR, CP) GR (or MV) GR (or CP) RB (or GR, CP) GR GR RB (or GR) Actions to be taken with respect to the references to local resources when migrating code to another machine. 38

Migration in Heterogeneous Systems p The principle of maintaining a migration stack to support Migration in Heterogeneous Systems p The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment 3 -15 39

Software Agents p What is a software agent? p “An autonomous unit capable of Software Agents p What is a software agent? p “An autonomous unit capable of performing a task in collaboration with other, possibly remote, agents”. p The field of Software Agents is still immature, and much disagreement exists as to how to define what we mean by them. p However, a number of types can be identified. 40

Types of Software Agent p Collaborative Agent – also known as “multi-agent systems”, which Types of Software Agent p Collaborative Agent – also known as “multi-agent systems”, which can work together to achieve a common goal (eg, planning a meeting). p Mobile Agent – code that can relocate and continue executing on a remote machine. p Interface Agent – software with “learning abilities” (that damned MS paperclip, and the illfated “bob”). p Information Agent – agents that are designed to collect and process geographically dispersed data and information. 41

Implementation Issues (1) p The architecture of the D'Agents system. 42 Implementation Issues (1) p The architecture of the D'Agents system. 42

Implementation Issues (2) p The parts comprising the state of an agent in D'Agents. Implementation Issues (2) p The parts comprising the state of an agent in D'Agents. Status Description Global interpreter variables Variables needed by the interpreter of an agent Global system variables Return codes, error strings, etc. Global program variables User-defined global variables in a program Procedure definitions Definitions of scripts to be executed by an agent Stack of commands currently being executed Stack of call frames Stack of activation records, one for each running command 43

Software Agents in Distributed Systems Property Common to all agents? Description Autonomous Yes Can Software Agents in Distributed Systems Property Common to all agents? Description Autonomous Yes Can act on its own Reactive Yes Responds timely to changes in its environment Proactive Yes Initiates actions that affects its environment Communicative Yes Can exchange information with users and other agents Continuous No Has a relatively long lifespan Mobile No Can migrate from one site to another Adaptive No Capable of learning p Some important properties by which different types of agents can be distinguished. 44

Agent Technology p The general model of an agent platform (adapted from [fipa 98 Agent Technology p The general model of an agent platform (adapted from [fipa 98 -mgt]). 45

Agent Technology - Standards p The general model of an agent platform has been Agent Technology - Standards p The general model of an agent platform has been standardized by FIPA (The “Foundation for Intelligent Physical Agents”) located at the http: //www. fipa. org website. p Specifications include: n n Agent Management Component. Directory Service. Communication Channel. Communication Language. 46

Agent Communication Languages (1) p Examples of different message types in the FIPA ACL Agent Communication Languages (1) p Examples of different message types in the FIPA ACL [fipa 98 -acl], giving the purpose of a message, along with the description of the actual message content. Message purpose Description Message Content INFORM Inform that a given proposition is true Proposition QUERY-IF Query whether a given proposition is true Proposition QUERY-REF Query for a give object Expression CFP Ask for a proposal Proposal specifics PROPOSE Provide a proposal Proposal ACCEPT-PROPOSAL Tell that a given proposal is accepted Proposal ID REJECT-PROPOSAL Tell that a given proposal is rejected Proposal ID REQUEST Request that an action be performed Action specification SUBSCRIBE Subscribe to an information source Reference to source 47

Agent Communication Languages (2) Field Purpose INFORM Sender max@http: //fanclub-beatrix. royalty-spotters. nl: 7239 Receiver Agent Communication Languages (2) Field Purpose INFORM Sender [email protected]: //fanclub-beatrix. royalty-spotters. nl: 7239 Receiver [email protected]: //royalty-watcher. uk: 5623 Language Prolog Ontology genealogy Content p Value female(beatrix), parent(beatrix, juliana, bernhard) A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information. 48

Summary - Processes p p p p Processes play a fundamental role in DS’s. Summary - Processes p p p p Processes play a fundamental role in DS’s. Threads play a central role in building systems that don’t BLOCK when performing I/O – key requirement. The “classic” process organization model is client/server, and we looked at the various ways to organize the client and the server components. “Object Servers” are a special case. Processes can migrate from system-to-system: for performance and flexibility reasons. Although a simple, and easy to understand, idea, actually realizing this is not that simple (especially within heterogeneous environments). Standards are immature in this area, but are gaining support within the community (eg, FIPA). 49

Homework Assignment p p p You are to produce a five page report on Homework Assignment p p p You are to produce a five page report on GRID COMPUTING. This is a topic that has generated considerable interest within both the academic and commercial distributed computing communities. Your five page report should answer the following questions and address the following points: n n n p What is GRID COMPUTING (GC)? How does GC differ from traditional distributed computing environments? Why is GC important? What type of distributed systems is GC suited to? Identify three GC environments? What plaforms do they run on? Is GC just another distributed computing fad? Format: A 4, typed, bound, single-spaced, 12 pt. A cover page should also be included, as should a page of annotated references (and these are NOT counted as one of the pages). 50