330 likes | 459 Views
Processes. Chapter 3. Thread Usage in Nondistributed Systems. Context switching as the result of IPC Process: a running program (mgmt. unit of OS) Thread: execution unit within a process Switching: Processes: expensive (CPU context, MMU, TLB, …) Threads: cheap (almost only CPU context).
E N D
Processes Chapter 3
Thread Usage in Nondistributed Systems • Context switching as the result of IPC • Process: a running program (mgmt. unit of OS) • Thread: execution unit within a process • Switching: • Processes: expensive (CPU context, MMU, TLB, …) • Threads: cheap (almost only CPU context)
Thread Design Issues • User-level threads: • +: create, destroy, switching very cheap, because without OS. • -: blocking system calls (e.g. communication) would block all threads. • parallelism is restricted • Kernel-level threads: • +: kernel can do context switching when blocking system calls are used. • more parallelism • -: create, destroy, switching are expensive (switches to kernel mode necessary). • Hybrid solution: • Seems to be the best one. • Use of user-level threads (thread package). • Use of kernel-level threads so-called light-weight processes (LWPs).
Thread Implementation • Combining kernel-level lightweight processes and user-level threads.
Multithreaded Clients (1) • Example: WWW Browser • Thread 1: get text • Thread 2: get image • Thread 3: get banner • … • Better responsiveness, but user may notice parallelism. • Multiple connections to server: • If server is replicated (i.e. horizontal distribution), different connections • correspond to different server instances. • more parallelism
Multithreaded Servers (1) • A multithreaded server organized in a dispatcher/worker model.
Multithreaded Servers (2) • Three ways to construct a server. • Finite-state machine (rather intricate): • Only one thread (that simulates multiple ones) • Loop: • Get next message. • Do some computation if needed. • Send asynchronous message(s) to device(s) (e.g. disk) – no blocking on I/O. • Go to first step (and receive next message, which may be from disk or from client).
Clients: User InterfaceThe X-Window System • The basic organization of the X Window System
Client-Side Software for Distribution Transparency • Access transparency: IDL-based stubs • Relocation/migration transparency: rebind within middleware (stub/proxy) • Replication transparency: see below • Failure transparency: time redundancy, use of caches as in browsers, … • Concurrency/persistence transparency: rather at server or intermediate server (transaction monitors manage concurrent transactions)
Servers: General Design Issues (1) 3.7 name to port mapping listens to all relevant ports • Client-to-server binding using a daemon as in DCE • Client-to-server binding using a superserver as in UNIX (Inetd server)
Servers: General Design Issues (2) • Handling interrupts: • Out-of-band data: highest priority (supported in TCP) • Server is interrupted (e.g. Unix signal) • Stateful/stateless server: • Stateful: Server holds information about clients. For example, which client has currently opened a file for writing. • Recovery is needed after crash • May enhance performance • Stateless: no information about clients is held • No recovery after crashes • Less performance • Sometimes servers keep information about client behavior • Cookies (web server information on user’s favorite pages kept at client side) • Problem: privacy
Object Servers: Object Invocation • Object server: • Server that invokes local objects on behalf of client requests • It does not implement a service, objects implement services • Only a room where objects live • Issues: • Transient objects: • In-memory ones that live as long as server lives (or shorter) • Create object at first invocation and delete it when no clients are bound to it : +: minimizes resources, -: some invocations may be slow • Create all transient objects at once • Code/data sharing: • All objects are separated (e.g. different segments) +: promotes security • But code sharing may be very useful for persistent objects (e.g. code of class in memory and data of different objects on disk) • Threading: • On demand / pool • Per invocation (sync needed) / per object (no sync needed)
Object Adapter (1) • Object adapter (also called object wrapper): • Software (part of middleware) that implements a specific • activation policy. • Activation policy: e.g. per object / per invocation thread. • Main idea: objects should be kept simple and should no know how they are invoked (+: reliability). • Object adapters are generic (independent from object) • They communicate rather with the skeleton/stub of the object and not with the object itself. • Objects are rather passive until invocated by adapter. • Multiple object adapters on same machine with different activation policies possible and desirable for reasons of flexibility.
Object Adapter (2) Object 2.1 Object 2.2 Object 1.1 Policy 1 Policy 2 • Organization of an object server supporting different activation policies.
Object Adapter (3) /* Definitions needed by caller of adapter and adapter */#define TRUE#define MAX_DATA 65536 /* Definition of general message format: adapter/client*/struct message { long source /* senders identity */ long object_id; /* identifier for the requested object */ long method_id; /* identifier for the requested method */ unsigned size; /* total bytes in list of parameters */ char **data; /* parameters as sequence of bytes */}; /* General definition of operation to be called at skeleton of object */typedef void (*METHOD_CALL)(unsigned, char* unsigned*, char**); long register_object (METHOD_CALL call); /* register an object: from stub */void unrigester_object (long object)id); /* unrigester an object: from stub */void invoke_adapter (message *request); /* call the adapter: from deMUX*/ • The header.h file used by the adapter and any program that calls an adapter.
Object Adapter (4) typedef struct thread THREAD; /* hidden definition of a thread */ thread *CREATE_THREAD (void (*body)(long tid), long thread_id);/* Create a thread by giving a pointer to a function that defines the actual *//* behavior of the thread, along with a thread identifier */ void get_msg (unsigned *size, char **data);void put_msg(THREAD *receiver, unsigned size, char **data);/* Calling get_msg blocks the thread until of a message has been put into its *//* associated buffer. Putting a message in a thread's buffer is a nonblocking *//* operation. */ • The thread.h file used by the adapter for using threads.
Object Adapter (5) Adapter thread • The main part of • an adapter that • Implements a • thread-per-object policy. Demultiplexer thread
Code Migration • Migration: shift entity (process, application, …) from A to B. • Why?: • - gain more performance: utilize lightly-loaded nodes or exploit parallelism • (e.g. search in the Web). • - enhance reliability/availability: separate faulty and well-behaved applications (rather new). • - be more flexible (see next slide) • Load: cumulative CPU requirements of ready-to-run processes, length of ready-to-run queue, utilization, … • Goals (related to performance): a) minimize computation time, b) minimize advent of communication (important in distributed systems) • Examples: • - client code is better executed at server, if too many data are needed to obtain some result. • - server code is better executed at client, if too many user interactions are needed prior to actual processing.
Dynamic Client Configuration(enhances flexibility) e.g. protocol implementation (language that server speaks) • The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server. • Issue: security
Models for Code Migration (1) • Mobility: refers to the fact that an entity can be migrated. • Weak mobility: only code part of entity (with some initialization data) is migrated. Entity can only begin computation at target node. • Java applets • a) code executed in same process (less secure but efficient, e.g. applets are executed in browsers) • b) code executed in different process (more secure, but resources like files are not protected, and less efficient) • Strong mobility: both code and whole state of entity (data, CPU registers, etc.) are migrated. • the entity (e.g. process) can continue computation on target node from where it has been stopped. • example: D’Agent • remote cloning: copy of entity on target machine, but original remains at sender machine (e.g. Unix fork and continue on different machine). • Sender-initiated: initiative of migration is taken at sender side (e.g. upload code to a server) • Receiver-initiated: initiative of migration is taken at receiver side (e.g. Java applets).
Models for Code Migration (2) • Alternatives for code migration.
Migration and Local Resources (1) • What to do with resources after a process has been migrated? • Resources: monitors, files, ports, libraries, … • Resource bindings may change after migration (unlike code and state) • Process-to-resource bindings: • Binding by identifier: Process needs exactly the resource used before migration. • new resource is equal old resource, e.g. local port • Binding by value: Process needs the value of the resource used before migration. • new resource is equivalentto old resource, e.g. programming library • Binding by type: Process needs a resource of a specific type. • new and old resources have same type, e.g. monitors, printer, … • Resource-to-machine bindings: • Unattached resources: Not bound to a specific machine, e.g. unshared file • Fastened resources: In principle independent of any machines, but de facto (e.g. enormous moving overhead) bound to a machine, e.g. Web database • Fixed resources: bound to a specific machine, e.g. devices
Migration and Local Resources (2) Resource-to machine binding Process-to-resource binding • MV: move resource • GR: use global reference • CP: copy resource • RB: rebind to (local) resource • Actions to be taken with respect to the references to local resources when migrating code to another machine. • Establishing global references may always solve the problem of resource bindings after migration, however it may introduce more overhead (e.g. communication, reconfiguring owners of global reference).
Migration in Heterogeneous Systems 3-15 • The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment • State-of-the-art: Use of a virtual machine (e.g. Java) • relies on only one language
Overview of Code Migration in D'Agents (1) proc factorial n { if ($n 1) { return 1; } # fac(1) = 1 expr $n * [ factorial [expr $n – 1] ] # fac(n) = n * fac(n – 1) } set number… # tells which factorial to compute setmachine … # identify the target machine agent_submit $machine –procsfactorial –vars number –script {factorial $number } agent_receive … # receive the results (left unspecified for simplicity) Main Program • A simple example of a Tcl agent in D'Agents submitting a script to a remote machine • agent_submit: sender-initiated weak migration (with separate process at receiver side)
Overview of Code Migration in D'Agents (2) proc all_users machines { set list "" # Create an initially empty list foreach m $machines { # Consider all hosts in the set of given machinesagent_jump $m # Jump to each host set users [exec who] # Execute the who command append list $users # Append the results to the list } return $list # Return the complete list when done} set machines … # Initialize the set of machines to jump toset this_machine # Set to the host that starts the agent # Create a migrating agent by submitting the script to this machine, from where# it will jump to all the others in $machines. agent_submit $this_machine –procs all_users -vars machines -script { all_users $machines } agent_receive … #receive the results (left unspecified for simplicity) Main Program • An example of a Tel agent in D'Agents migrating to different machines where it executes the UNIX who command • agent_jump: sender-initiated strong migration • agent_fork: sender-initiated remote cloning
Implementation Issues (1) Agent start/end, migration, agent-level communication Agent mgmt (e.g. Ids), authentication, communication • The architecture of the D'Agents system.
Implementation Issues (2) • The parts comprising the state of an agent in D'Agents.
Software Agents in Distributed Systems • Important properties by which different types of agents can be distinguished. • Other functional properties: • Interface agents: personal agents that assist users in the use of applications (usually • learning/intelligent agents) • Information agents: process information from different sources (usually mobile agents that • roam the network)
Agent Technology Agent communication channel Create/delete agent, end points mapping, … What do other agents offer? • The general model of an agent platform (FIPA model). • FIPA: Foundation for Intelligent Physical Agents
Some Agent Applications • Searching (e.g. in the Web): • Enhances parallelism. • Mobility is asset. • E-Commerce: • Walk in the network to find best offers. • Pay at seller side. • Issue: security. • Network management: • Performance, fault, configuration mgmt, and other functions. • Cooperation is asset: networks may span over different organizational domains. • Examples: a) Construct new complex services in cooperation with other agents (on-the-fly!). b) Solve performance reductions or fault situations by cooperating with agents in other domains. • Computer-assisted learning: • Intelligence is asset: agent should be able to adapt to student’s knowledge. • Relevant in distributed systems, if (distributed) agents cooperate in doing their work.
Agent Communication Languages (1) • Examples of different message types in the FIPA ACL giving the purpose of a message, along with the description of the actual message content.
Agent Communication Languages (2) • A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information.