Processes

1. Processes Chapter 3

2. Processes • Process: Program in execution. • In DSs, more concepts come into consideration, eg. Multi-treading, process migration, code migration, • Threads: finer granular than processes, multiple thread of control in a single process. • Agents at the end of this chapter.

3. Threads • Process :: Virtual processor • Process table, used to manage virtual processors. • Separation of processes domain in order to prevent intervention! • Concurrency transparency exists, but expensive! • Threads are similar to processes, but no attempt to provide such level of concurrency transparency gaining performance. • Thread context consists of nothing except CPU switch + little tasks.

4. Threads-2 • Blocking of the whole process when a block system call is executed; while we need to continue other aspects of the task. • Examples: An spreadsheet with two tasks, data input and broadcasting of changes. • Utilizing the processing power of more than one CPU in a program. • RPC with single-tread processes.

5. Thread Usage in Nondistributed Systems • Context switching as the result of IPC

6. Threads-4 • Thread switching can be done in the user area, thus no context switch! • Threads are implemented in the form of a tread package. Operatins include create, destroy + operations for synchronization • Two approaches • Thread library and entirely in the user mode • Cheap   Blocking of the process will block all! • Support of kernel to be aware and to schedule them • Expensive  no benefit of using threads!!

7. Thread Implementation • Combining kernel-level lightweight processes and user-level threads. • Several LWP in the context of a single process. • Multithread application is constructed by creating threads, and assign each tread to a LWP • Each LWP finds a running thread and Context switch of LWPs are done in the user space

8. Multithreaded Clients & Servers • Browsing a web page containing several links • Paralled downloading of pages through multithreading to replicas of a web-server, when thr server is the bottleneck. • Main usage in DSs is for serevrs, for parallelism and higher performance.

9. Multithreaded Servers (1) • A multithreaded server organized in a dispatcher/worker model.

10. Multithreaded Servers (2) • Three ways to construct a server.

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

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

13. Servers • Iterative Servers • Concurrent Servers, through threads or even forking new processes. • Next slide …. • Staeless Server: does not keep info on the state of its clients; can change its own state regardless of the clients:: Web Server • Statefull Server: File Server • Object Server: A server to support distributed objects.

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

15. Object Adapter (1) • Alternatives for Invoking Objects • Only one way to invoke …Inflexible • Diffeerent policies • Making a transient object at the first invocation • Each object is located in a memory segment of its own. • Activation Policy: How to invoke an object? • Organization of an object server supporting different activation policies. • Object Adapter: Group objects per policy

16. 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 adapter and any program that calls an adapter.

17. Object Adapter (3) • The thread.h file used by the adapter for using threads. 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. */

18. Object Adapter (4) • The main part of an adapter that implements a thread-per-object policy.

19. Code Migration • Till now, passing data as parameters to a remote process/thread/object. • Sometimes, it is needed to pass a program, EVEN while it is being run. • Code migration in • Homogeneous systems • Heterogeneous systems • Security issues are discussed in section 8.

20. Motivation • Getting performance through migrating processes from heavily-loaded machines to lightly-loaded ones • Load distribution is a very important player! • Optimizing computing capacity is less an issue than minimizing communication! • Scenario: A process handling a large quantity of data in a client-server architecture. Which part should be migrated? Data-Centric or UI centric? • Flexibility is another motivation.

21. Reasons for Migrating 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.

22. Models for Code Migration • Alternatives for code migration. • Assuming a process has 3 segments: code, resource, execution

23. Mobility • Weak: transfer code + initialization data. Program always starts from ZERO  simple; target machine should be able to execute the code:: Java Applet • Strong: the execution segment can also be transferred  The running process should be suspended, transferred, and resumed:: D’Agents • Initiator: Sender (sending to a compute server, or a query to the search engine :: server should know all its clients) or Receiver (Java Applet; can be done anonymously)

24. Migration and Local Resources • Resource segment cannot be transferred simply! • Example: binding to a TCP port! Reference to a file. • 3 types of process-to-resource bindings: • by identifier  process requires the referenced resource, nothing else (a URL) • by value  another resource can be used, e.g. general libraries in C or Java. • By type  references to monitor, printer, .. • Unattached resources, Fastened resources (local DBSs), and Fixed resources (bound to local resources)

25. Migration and Local Resources • Actions to be taken with respect to the references to local resources when migrating code to another machine. GR: Establish a global system wide reference; MV: Move the resource; CP: Copy the value of resource; RB: Rebind process to locally available resource Resource-to machine binding Process-to-resource binding

26. Migration in Heterogeneous Systems • Till now, it is assumed that the code can be run there • In the case of weak mobility, new compilation! • In the case of strong mobility, migration of the execution segment.  at least we need the same H/W architecture and the same OS. • Execution segment includes: data (private to the process), current stack (temp data, platform-dependent register values!) & PC. • A solution for procedural languages in the next slide: Restricting the migration on calling a subroutine

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

28. D'Agents • An agent in D’Agents is a program that can migrate. • Programs can be written in any language that can be run in the target machine (Tcl, Java, Scheme) • Mobility • Sender-initiated weak, separate process, through agent_submit command • Next slide • Process migration strong, through agent_jump command, the caller process is suspended; all segments (code, resource, execution) are marshaled and sent for the destination. A new process is initiated and resume execution after the agent_jump call. Now the suspended process exit. • Cloning strong

29. Overview of Code Migration in D'Agents (1) A simple example of a Tcl agent in D'Agents submitting a script to a remote machine (adapted from [gray.r95]) 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)

30. Overview of Code Migration in D'Agents (2) An example of a Tcl agent in D'Agents migrating to different machines where it executes the UNIX who command (adapted from [gray.r95]) 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)

31. Implementation Issues (1) • The architecture of the D'Agents system. Language independent core Start and end an agent, Various migration operations Agent Mngmnt, Authentication, Inter-agent Communication Messaging

32. Implementation Issues (2) • The parts comprising the state of an agent in D'Agents.

33. Software Agents • Independent views of execution are concluded in Software Agents. • Autonomous units capable of performing a task in collaboration with other, possibly remote agents. • Collaborative agents: autonomy and cooperation. • Mobile agents: Ability to move between different machines. • Interface agent: assist end-user in the use of one or more applications. • Information agent: manage information from different sources

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

35. Agent Technology The general model of an agent platform (adapted from [FIPA 98-mgt]). ACC: Agent Communication Channel, which provides the abstraction of a reliable/ordered/…. channel.

36. Agent Communication Languages (0) • Communication between agents in the application level. • A strict separation between the purpose of a message & its content. • Purposes of the message in the next slide (FIPA).

37. Agent Communication Languages (1) • 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 information.