210 likes | 387 Views
CS 603 Threads, Processes, and Agents. March 18, 2002. Goal: Operate at Remote Site. Client-Server Model: Client requests service Scope of available services known in advance Remote Procedure Call Call existing procedure at remote site
E N D
CS 603Threads, Processes, and Agents March 18, 2002
Goal: Operate at Remote Site • Client-Server Model: • Client requests service • Scope of available services known in advance • Remote Procedure Call • Call existing procedure at remote site Problem: Remote Site must already know what we want to do!
Goal: Operate at Remote Site • How is this handled in non-distributed system? • Write and run a program! • Are there single-system analogues to starting arbitrary operation? • Processes • Threads
Process Model • Basic idea: Virtual MachineModel “complete ownership” of machine • Memory • Files • Processing • How does this fit with Distributed System? • It doesn’t • Solution: Multiple Processes • Each process on different virtual machine • In Distributed System, different real machine
Multiple Processes: How • Fork: Create child as “clone” of current process • Wouldn’t execution be same as parent?Process ID is new, as are a few other things • Exit: Terminate process • Frees resources, closes files, etc. • Wait: Parent waits for child to terminate • Block until child exits • What about multiple children?
Inter-process Communication Not very interesting if processes completely independent • Files: Process can write and read same file • Synchronization difficulties • Pipes: One-way FIFO buffer between processes • Sounds like stream-oriented communication • Shared Memory • Explicitly declared shared area • Also semaphore primitive This is beginning to sound like a distributed system!
Remote Fork • Why isn’t “Remote Fork” a primitive • Fork clones process • Copies memory • Same open file descriptors • Expensive at best, infeasible at worst • Solution: Process as “local proxy” • Fork creates process • Child uses RPC/? to start remote execution
Threads • Multiple activities in same address space • Process model creates new address space • Threads share – i.e., all memory is shared • Shared variables for communication • Mutex – mutual exclusion primitive • Condition variable – wait/signal • Join – wait for particular process • Even more difficult in distributed system • Requires distributed shared memory model • Again use as local proxy to start remote code
So where are we? • Models for Remote Processing • Server: Request documented service • RPC: Request execution of existing procedure • What if operation we want isn’t offered remotely? • Solution: Agents / Code Migration
Code Migration • Process consists of: • Code • Resources (files, devices, etc.) • Execution (data, stack, registers, etc.) • Fork copies everything • Is this needed? • Solution: Copy part of the process
Types of Code Migration • Weak mobility: Copy only code • Program starts from initial state • Example: Java applets • Strong mobility: Copy code and execution • Resume execution where it stopped • But doesn’t necessarily have same resources (less than fork) • Example: D’Agents (later), cluster computing (Condor, LSF)
Types of Code Migration • Sender Initiated • Receiver Initiated • Examples: • Java Applets Receiver Initiated • Cluster computing Sender Initiated? Central manager initiated?
Types of Code Migration • Where executed? • In target process • In new process • Strong Mobility: Move vs. Copy • Migrate process: Ceases at originating site • Clone process: Two copies in parallel
Types of Code Migration From Andrew Tanenbaum, Distributed Operating Systems, 1995.
The Hard Part: Resources • Migrated process still needs resources • Options to Connect to a Resource (Fugetta et al., 1998): • Binding by identifier (e.g., URL) • Attach to the same resource • Binding by value (e.g., standard libraries) • Bind to equivalent resource • Bind by type (e.g., “local printer”) • Bind to resource with same function
The Hard Part: Resources • Alternative: Move the Resource • Unattached resources (e.g., data files) • Relatively easy to move • Fastened resource (e.g., database) • Expensive to move • Fixed resource (e.g., communications endpoint) • Can’t be moved
What about Heterogeneity? • Assumption: Same code runs at both source and target • Weak mobility: Can compile/execute same source • Strong mobility: More difficult • C/Pascal/etc.: Mobile only at subroutine call • Use same mechanisms as RPC • Translate parameters and stack/globals • Return goes back to original machine • Java: Hide heterogeneity in virtual machine
What Next? • Specific Example: D’Agents • Research Project at Dartmouth • Basic idea: Mobile agents • Based on Tcl • Project 3 will use D’Agents • Still working on appropriately scoped task • Feel free to start reading • http://agent.cs.dartmouth.edu