Processes

1. Processes Chapter 3

2. Processes • Process is a program in running state • PROCESSES ARE THE BUILDING BLOCKS OF DISTRIBUTED SYSTEMS, ESPECIALLY IN unix TERMINOLOGY • A process is run as if it is executed by a virtual processor • The sharing of the same CPU or resources such as memory, hard disks, and communication medium is made transparent by the operating system

3. Implementation of Concurrent Processes • Operating system switches from process to process during its execution whenever necessary, according to certain scheduling principle. • With single CPU, the concurrency is achieved y overlapping I/O of one or more processes with execution of one. • A process context may be swapped between memory and hard disk, if necessary, to be handled at the same time by the same processor and in the same memory.

4. Threads • Threads provide a finer degree of concurrency with less transparency… • A thread context switching is faster than that of process. • \with thread switching context is smaller, comprising only CPU state. • Data (memory) protection in between the threads is left to the application. • Use of threads requires more sophisticated application development, compared to that of process

5. Context switching as the result of IPC • Process A is put on halt, process B executes to receive the IPC

6. Thread Usage in Nondistributed Systems • Use of threads can provide dramatic improvement in performance, as part of a program may not have to wait for the other part, thus increasing the concurrency and performance. • Threading can be in the context of an application, by the OS kernel, or both. • Threads are implemented using a special thread library, providing thread creation, destruction, synchronization. • Application level threads does not provide efficient concurrency, a blocking system call block the entire application…

7. Thread Usage in Nondistributed Systems • A kernel level thread operates like a process, context switching is required, making it as expensive as multiple processes. • The best performance can be achieved by user level threads and so called kernel level light weight process-LWP. • LWP, once created run a scheduling routine to determine one of the user level threads… • So context switching is done at user level, with minimum support from the operating system in thread switching

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

9. Thread Usage in Distributed Systems • With threads, it is possible to implement concurrent communications. • This is an important requirement for distributed systems • This is prerequisite for multithreaded clients and servers. • When one thread block, the other will continue executing.

10. Multithreaded Clients • Clients may be programmed to request data from more than server or clients may need to mix fast and slow operations. • For example, a web browser may have to fetch different part of the display from different servers, or some locally some through servers. • All such cases can be implemented using multithreads.

11. Multithreaded Clients-Examples • X-Window (X) is used to control bit mapped terminals, comprising of monitor, keyboard, and mouse. • X kernel is part of the OS that controls the terminal… • Window manager is designed to manipulate the screen • The devices and events are associated to the related window… • X allows compound documents (collection of different kinds) to be maintained…

12. The X-Window System • The basic organization of the X Window System

13. Client-Side Software for Distribution Transparency Client-proxy • A possible approach to transparent replication of a remote object using a client-side solution. Client sees one return value from one of the replicas only

14. Multithreaded Servers • Servers are often designed to serve more than clients concurrently, • This can only be achieved either through multiple processes or multiple threads. • This is important both for uniprocessor and multiprocessor cases. • Multithread solution is cleaner, simpler and faster…

15. Multithreaded Servers-example (1) • A multithreaded server organized in a dispatcher/worker model. Clients requests are received at the dispatcher thread and dispatched to worker threads

16. Different Ways of Server Implementation (2) • Three ways to construct a server. • Threads allow conventional programming mode • FSM allows is hard to program, as the state need to be recorded and remembered to come back to it, as part of the change in the state…

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

18. Server Design Issues • Iterative sever • Concurrent server • Super server • Stateless server • Stateful Server • Cookies in web servers • Object servers

19. Object Servers • An Object server-ObjServ is tailored to serve distributed objects, which has been gaining importance… • ObjServ is a place where objects live. • An object server may invoke an object using • One thread per object or • One thread per invocation or • Different policies: transient objects (created when needed, aborted when finished ), objects have a memory partition of their own, code shared, etc.

20. Object Adapter (1): objects are grouped per policy • Organization of an object server supporting different activation policies. • One ObjAdapter for each policy, eg. Implementation of a specific invocation

21. Object Adapter (2) /* 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 obj adapter and any program that calls an adapter.

22. Object Adapter (3) 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, assuming that a thread package is available.

23. Object Adapter (4) • The main part of an adapter that implements a thread-per-object policy. • Imp of adapter is independent of the object for which it handles invocation

24. Code Migration • Passing programs in global environment rather than passing control… • Process migration is one well known migration type, used in UNIX and other operating systems… • Reasons for code migration: • Performance, in terms of load balancing • Parallelism • Flexibility, matching the application design • Dynamic configuration

25. Migrating Client Code • 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. Models for Code Migration • Alternatives for code migration.

27. Migration and Local Resources Resource-to machine binding Process-to-resource binding • Actions to be taken with respect to the references to local resources when migrating code to another machine: GR-Global Ref, MV-Move Resource, CP-Copy Value, RB:Rebind proc to loc avail resource

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

29. D’Agent: Tcl-Tool command language script based • D’agent is a Tcl script program that can migrate between heterogeneous machines • Tcl, like Java and Scheme is an interpretable language, which makes it easily migratable in heterogeneous environments • This migration based mobility is achieved by weak (usually script based) or strong (usually process based) mobility.

30. Example Migratable code in D'Agents: Taking factorial of a number n 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 set machine … # identify the target machine agent_submit $machine –procs factorial –vars number –script {factorial $number } agent_receive … # receive the results (left unspecified for simplicity) • A simple example of a Tel agent in D'Agents submitting a script to a remote machine (adapted from [gray.r95])

31. Example Migratable code in D'Agents (2):Unix Who command all_users $machines proc all_users machines { set list "" # Create an initially empty list foreach m $machines { # Consider all hosts in the set of given machines agent_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) • An example of a Tel agent in D'Agents migrating to different machines where it executes the UNIX who command (adapted from [gray.r95])

32. Implementation Issues (1) • The architecture of the D'Agents system, Server manages the agent each as a separate process; RTS: Run Time System implements the agent (start-end etc,).

33. Implementation Issues (2) • The parts comprising the state of a running agent in D'Agents: • In case of migration the content of all the tables and the stacks is marshaled into a stream of bytes and shipped to the target machine, where it unmarshaled into the new state, executed as a new process

34. Software Agents in Distributed Systems • Autonomous process capable of inducing changes and reacting to changes in its environment, possible collaborating with other agents. • An agent can be mobile as well as stationary. • An agent can be adaptive with a certain degree of intelligence. • An agent can play a role of an interface or information or security type

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

36. Technology to support agent based application development ACC-Agent Comm Ch • The general model of an agent platform (adapted from [FIPA-Foundation for Intelligent Physical Agents-98-mgt]).

37. Agent Communication Languages as part of Agent Technology • 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.

38. Agent Communication Languages (2) • A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy as an ontology type information.