1 / 36

Processes and Distributed Computing

Processes and Distributed Computing. Issues: moving processes around design of server and client processes migration of processes/programs agent programs Processes without Threads are almost useless in distributed processing. Process Communication. Usual Mechanisms are: Pipes

inara
Download Presentation

Processes and Distributed Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Processes and Distributed Computing • Issues: • moving processes around • design of server and client processes • migration of processes/programs • agent programs • Processes without Threads are almost useless in • distributed processing

  2. Process Communication • Usual Mechanisms are: • Pipes • Message Queues • Shared Segments • What do they all have in common?? • Context switching as the result of IPC

  3. Threads as a Core Mechanism • A thread can be seen as a program in execution on a virtual processor • Thread context: CPU status + some more information on (needed for thread management). • For instance a thread may be currently blocked • on a mutex variable and this information can be used so • that it does not get scheduled for execution.

  4. Why Threads are Useful in Distributed Systems?? • If a system is implemented as a single-threaded process that blocks on a system call, the whole process gets delayed.. • If a multiprocessor system is available, threads can be executed with different processors (real parallelism). • How are threads implemented?

  5. Options for Implementation • Threads are provided in the form of a thread package. • Advantages (of a library implemented entirely in user-space): • Cheap to create/destroy threads • Switching among threads is inexpensive (a few instructions only- no need to change memory maps, deal with CPU, flushing the TLB etc. • Disadvantages (of the user-space library): • Invocation of a blocking system call will block the entire process.. (bad as no other thread can proceed..)

  6. Other Options • Kernel-threads… • but this has disadvantages as it essentially suffers from the many possible thread-switch operations (which have the same cost as process context switches). • Approach in between: Lightweight Processes (LWP)

  7. Light Weight Processes • A LWP runs in the context of a process • Multiple LWPs may exists per process • A user-thread package available for applications (to create/destroy threads) – implemented entirely on the user-space. • The package provides sync primitives (mutexes/condition variables) • Every LWP can run its own user-thread. • Assigning a thread to a LWP is implicit (hidden from the programmer).

  8. LWPs & User Threads • LWP are created by system calls and is given its own stack. • When an LWP is created runs the sched to find a thread to run • If there are more than one LWP, then all of them run the sched. • The thread table is kept in user-space (protection is done by mutexes)-sync does NOT need kernel-support. • When a LWP find a runnable thread context switches to it. • If a thread needs to block on a mutex or cond variable, it does its own administration and then calls the sched. When another runnable thread is found, a context switch is made to that thread.. • End Result: the LWP need not be informed about the last context switch (which happens entirely in user-space).

  9. Blocking Threads • When a thread makes a blocking system call: • Change from user-space to kernel • If the current LWP can continue (with another thread it does so) • Otherwise, the OS may decide to run LWP • Ultimately another context switch needs to be made back to kernel. • Similar approach: Scheduler Activations [Anderson 1991] • When a thread block (on a blocking system call) the kernel does a upcall to the thread package and calls the scheduler routine to pick one thread for execution.

  10. Thread Implementation • Combining kernel-level lightweight processes and user-level threads.

  11. Threads in Distributed Systems • Convenient mechanism to allow blocking calls without blocking entire processes/systems • Mechanism to hide network latencies and delays. • Example: a browser (client) program and the way it retrieves and displays information. • - multiple operations may happen concurrently.

  12. Multithreaded Servers Threads are extremely useful when one writes server code • A multithreaded server organized in a dispatcher/worker model.

  13. Multithreaded Servers • In Finite-state machine model, the only process in the server • services requests but also marks the state of each process. • Finite-State machine model: complicated to program • Three ways to construct a server.

  14. Client Organization:X-Window System Example • It does provide functionality transparency for the Interface • The basic organization of the X Window System

  15. Client-Side Organization for Data Distribution Transparency Failure transparency(at the client site)?? If a client cannot connect to a server after a number of attempts, it does try another one.. • A possible approach to transparent replication of a • remote object using a client-side solution.

  16. Design Issues for Servers • Iterative server • The server itself handles the request and if possible returns a result • Concurrent server • The server passes the request to a different server (thread) • After that it waits for the next incoming request… • Endpoints/Ports: • How do clients know about them?? • Some are standard ie, ftp is at 21, http at 80 etc. • Some services do not require pre-assigned endpoint. • One solution is DCE style • Another use a superserver (ala Unix) – forks a new process to handle incoming requests (via the inetd)

  17. Servers Design Issues • Client-to-server binding using a daemon as in DCE • Client-to-server binding using a superserver as in UNIX

  18. Server Design Issues • How to interrupt a server? • Exit the application • Send out-of-band data (separate data and control streams) • Stateless servers • Does not keep any information about the state of clients • Stateful servers • A file server that allows a client to keep a local copy of a file and the client does updates on the file. • Plus: can improve performance (as far as the client is concerned) • Minus: in light of a crash the server have to re-acquire the “state-of-affairs” just before the crash… • Cookies • Why are they used? What is good/bad about them?

  19. Object Servers • Developed to support distributed objects • An object server does not provide a specific service • Services are implemented by various objects resident in the server (or various servers). • Object • Data representing its state • Code (with the implementation of the methods). • Issue: how does a server invoke its objects? • In a multi-threaded server, each object may be assigned a thread. • Alternatively, a thread can be used for each invocation request.

  20. (Activation) Policies for Invoking Objects • Policy I: An object is generated the first time it is invoked and if it is transient it has to go when no client binds to it.. • Policy II: An object is always alive waiting to be contacted. • Policy III: An object is generated for the first time it is invoked and remains alive until Greece becomes a rational place.

  21. Object Adapter • Decisions on how to invoke an object are known as activation policies • Mechanism that groups objects together per activation policy is called • object adaptor/object wrapper. • Adaptors are unaware of the specific interfaces of the objects they control. • Organization of an object server supporting different activation policies.

  22. Object Adapter /* Definitions needed by caller of adapter and adapter */#define TRUE#define MAX_DATA 65536 /* Definition of general message format */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 */void unrigester_object (long object)id); /* unrigester an object */void invoke_adapter (message *request); /* call the adapter */ • The header.h file used by the adapter and any program that calls an adapter.

  23. Object Adapter 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.

  24. Object Adapter • The main part of an adapter that implements a thread-per-object policy.

  25. Why Migrating of Code? • Needed often for better Load Sharing and Balancing • Move work from lightly to heavily loaded nodes. • The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server.

  26. Types of Mobility • Processes consist of [Fugetta 98] • Code segment (set of instructions that make up the program) • Resource segment (references to external resources) • Execution segment(stores the current execution state) • Weak mobility: transfer only the code section (Java applets). • Strong mobility:transfer the execution section as well (D’Agents).

  27. Models-Alternatives for Code Migration

  28. Migration and Local Resources • Transferring a resource is sometimes exceedingly difficult (if not impossible) • Move a process that holds a specific TCP port.. • Move a process that accesses a file via a URL. • [Fugetta 98] classifies process-to- resource bindings • By identifier (the strongest) • By value (weaker – C library that may be local but in a different location in the target FS). • By type (process indicates that it needs –references- specific type of resources such as printers, monitors, etc

  29. Local Resources • If and how a reference should be changed depends on whether that resource can be moved along to the target machine. • Resource-to-machine bindings • Unattached resources (ie, data files – can be easily moved around) • Fastened Resources(may be moved but expensive – ie, databases, web sites etc) • Fixed Resources (specific site resources such as local communication endpoints).

  30. Migration and Local Resources Resource-to machine binding Process-to-resource binding GR: establish a global systemwide reference MV: move the resource CP: copy the value of the resource RB: rebind process to locally available resource • Actions to be taken with respect to the references to local resources when migrating code to another machine.

  31. Migration in Heterogeneous Systems Weak mobility possible only when a program migrates between Procedure calls (use idea of migration stack-machine independent) 3-15 • The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment

  32. Agents.. • Agent is an autonomous process that can react to, and/or initiate changes in its environment (possibly with the collaboration of other processes and/or users).

  33. Software Agents in Distributed Systems • Some important properties by which different types of agents can be distinguished.

  34. Agent Technology • The general model of an agent platform (adapted from [fipa98-mgt]).

  35. Agent Communication Languages • Examples of different message types in the FIPA ACL [fipa98-acl], giving the purpose of a message, along with the description of the actual message content.

  36. Agent Communication Languages • A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information.

More Related