CS 603 Threads, Processes, and Agents March 18, 2002

Goal: Operate at Remote Site Client-Server Model: –C–Client requests service –S–Scope of available services known in advance Remote Procedure Call –C–Call existing procedure at remote site Problem: Remote Site must already know what we want to do!

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 Machine Model “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

Resource Binding Resource to Machine Binding Process to Resource Binding UnattachedFastenedFixed IdentifierMoveGlobal Reference ValueCopy ValueGlobal Reference TypeRebind Locally Rebind locally Rebind Locally

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 –