Processes and Threads

Processes and Threads

Key Topics (Connections)

• Processes → Threads: Threads provide lightweight concurrency within processes, reducing overhead.
• Threads → KLT / ULT: KLTs enable true parallelism; ULTs are efficient but single-processor only.
• Threads → Hybrid / LWP: Combine KLT and ULT benefits for efficient scheduling and parallelism.
• Threads → Scheduler Activations: Coordinate blocked threads without halting processes.
• Threads → Distributed Systems: Improve local node performance; memory is not shared across nodes.
• Multithreaded Clients → Latency Hiding: Overlap network and local processing for faster responsiveness.
• Multithreaded Servers → Concurrency: Handle multiple requests efficiently, avoiding process-forking overhead.
• Finite-State Machine Servers → Simulated Parallelism: Save state and switch tasks during blocking I/O.
• Virtualization → Resource Abstraction: Provide concurrent execution and full computing environments.
• Client-Side Software → Transparency: Hide network, location, and failure complexities.
• Server Design → Clusters: Enhance scalability, reliability, and performance via load balancing, failover, and HPC.
• Server Clusters → Three-Tiered Architecture: Separate access, application, and data tiers for efficiency.
• Code Migration → Load Balancing & Parallelism: Move code/processes to reduce communication and increase flexibility.
• Code Migration → Sender / Receiver Initiated: Offload busy sites or let idle machines take work.
• Code Migration → Security & Resources: Use sandboxing and proper resource handling to maintain bindings.
• VM Migration → Strong Mobility: Move entire computing environments, including resources for flexibility and maintenance.

Key Idea: Processes, threads, virtualization, server clusters, and code migration together optimize concurrency, parallelism, resource management, and transparency in distributed systems.

Overview

• Processes and threads play a key role in distributed systems, enabling concurrent execution and efficient resource utilization.
• Processes can be structured with multiple threads to handle tasks concurrently within the same program.
• Synchronous communication allows overlapping communication latencies with local processing, improving performance.
• Process migration helps achieve load balancing by moving processes between nodes.
• Server design involves addressing issues like concurrency, scalability, and resource management.
• Virtualization abstracts hardware and system resources, enhancing flexibility and isolation in distributed systems.

Key Idea: Processes, threads, communication strategies, process migration, server design, and virtualization collectively enable efficient, flexible, and scalable distributed systems.

Processes and Threads

• Processes provide concurrency transparency in operating systems, allowing multiple programs to execute seemingly simultaneously.
• Multiple processes on a single computer share CPU(s), memory, and disk using techniques like multiprogramming, multiprocessing, and process isolation.
• Groups of processes can cooperate to solve large problems through parallel programming.
• Multithreading offers concurrency with lower overhead compared to multiple processes in some cases.

Key Idea: Processes and threads enable concurrent execution, resource sharing, and parallel problem-solving, with threads providing a lighter-weight alternative to full processes.

Problems with Processes

• Process creation incurs overhead from initializing memory segments, the runtime stack, and other address space setup tasks.
• A blocking system call halts the entire process, reducing efficiency.
• Context switching between processes introduces significant overhead.
• Single processes cannot exploit multiple processors or cores for parallelism.
• Before threads, multiple child processes were created to achieve parallel execution.

Key Idea: Processes have high overhead and limited parallelism, motivating the use of threads for more efficient concurrency.

Large Applications

• UNIX creates cooperating programs using the fork() system call, where a parent process spawns multiple child processes.
• Child processes start as clones of the parent process.
• Each child can execute a portion of the parent’s code concurrently.
• The exec system call can replace a process’s existing code, data, heap, and stack with a new executable, allowing an existing process to run a new program.

Key Idea: Large applications use process creation and execution mechanisms like fork() and exec to enable concurrent execution and program replacement within processes.

Forking a New Process

• The fork/exec approach creates a family of related processes, where fork() spawns a new process and exec() can replace its code with a new program.
• Examples and detailed explanations are available at YoLinux Fork/Exec Tutorial and Amparo Fork/Exec Examples.
• A Fork Bomb is a malicious or accidental situation where processes repeatedly fork(), rapidly exhausting system resources.

Key Idea: fork/exec enables process creation and program replacement, but uncontrolled forking (fork bomb) can crash the system.

Process Table

• The Process Table is a data structure maintained by the operating system to keep track of all active processes.
• It stores information such as process ID, process state, CPU registers, memory pointers, open files, and scheduling information.
• The table allows the OS to manage processes efficiently, including creation, scheduling, and termination.
• It is needed to enable process management, context switching, and resource allocation in a multitasking system.

Key Idea: The Process Table provides a central record of all processes, supporting efficient execution, resource tracking, and multitasking in the operating system.

This diagram illustrates how an operating system manages multiple processes using a Process Table and Process Control Blocks (PCBs). The Process Table acts as a central directory, where each running process is listed with a unique Process ID (PID). Each entry in this table contains a pointer to a corresponding PCB, which is a detailed data structure holding all the essential information about that specific process. This information, often called the process’s context, includes the program counter, CPU registers, current state (e.g., running, waiting), memory address space, and a list of open files. By maintaining this structure, the operating system can efficiently manage and switch between processes by locating a process’s PCB through the Process Table and using the stored information to save or restore its execution state.

This diagram illustrates a detailed process structure within a modern operating system kernel. The Process Table (Proc Table) serves as the main directory, where an entry for a specific process (proc[n]) acts as a container for resources. This process entry points to one or more Kernel Threads (kthread), which are the actual units of execution that the OS schedules. All threads within the same process share a common Virtual Address Space (VAS), which defines the memory layout for the process. This VAS is composed of multiple memory regions (Pregion), such as code, data, and stack segments. Finally, each process has a Uarea (User Area) that stores process-specific kernel information, including user credentials and the kernel stack, linking all these components together to represent a complete, executing program.

The main difference is that the first diagram shows a simple, classic model of a single-threaded process, while the second diagram shows a more complex, modern model of a multi-threaded process.

Key Differences

• Execution Model:
  - The first diagram shows a one-to-one relationship. One entry in the Process Table points to one Process Control Block (PCB). This PCB contains everything needed to run the process, implying it has only one thread of execution.
  - The second diagram shows a one-to-many relationship. One process entry point to a list of multiple Kernel Threads. Each thread is an individual path of execution that the OS can schedule.
• Structure and Resource Sharing:
  - In the first diagram, the Process Control Block (PCB) is a single, all-encompassing data structure. It holds both the execution details (registers, program counter) and the resource information (memory space, open files).
  - In the second diagram, these roles are split. The process acts as a container for resources (like the Virtual Address Space — VAS), while the kernel threads are the units of execution that share those resources.
• Level of Detail:
  - The first diagram is a high-level, conceptual model that’s easy to understand.
  - The second diagram is a more detailed, implementation-level view that reflects how modern operating systems like Linux or Solaris actually manage processes and threads.

In the modern, multi-threaded model (the second image), the responsibilities of the classic PCB have been split up.

• The Virtual Address Space (VAS) represents only the memory layout of the process (the “Address space” field from the first diagram). This is a resource that all threads within that process share.
• The execution details (like the Program counter and Registers) are now stored within each Kernel Thread (kthread). Since each thread executes independently, each one needs its own set of registers and its own program counter.

Table comparing where the information lives in both models

Large Applications: Overhead

• Forking a new process duplicates many existing process structures, causing unnecessary work if followed by exec().
• Cooperating processes use IPC mechanisms like pipes, message queues, and shared memory to exchange information.
• The operating system handles these interactions, introducing overhead.
• Overhead arises from multiple mode and context switches needed to create, schedule, and access shared memory among processes.

Key Idea: Process creation and interprocess communication introduce significant overhead, making threads a more efficient alternative for large applications.

Overhead Due to Process Switching

This diagram illustrates the three main steps of a context switch performed by an operating system to change which process is executing. The process begins at step S1, where Process A, running in user space, triggers a mode switch into kernel space, typically due to a system call, I/O request, or a timer interrupt. Once inside the operating system, the scheduler decides to run a different process. At step S2, the OS performs the actual context switch: it saves the complete execution state (registers, program counter, etc.) of Process A and loads the state of Process B. Finally, at step S3, the OS performs another mode switch, transitioning from kernel space back into user space, which allows Process B to begin or resume its execution.

• Context switching introduces direct overhead as the CPU saves and loads process states.
• Indirect costs can be higher, such as cache data being pushed out and later restored.
• Interprocess communication (IPC) often triggers additional context switches, adding to the overhead.

Key Idea: Process switching, especially during IPC, incurs both direct and indirect overhead, affecting system performance and efficiency.

Large Applications: Multi-threaded

• Modern languages support multi-threaded processes, allowing a single process to contain multiple threads instead of spawning separate programs.
• Benefits over multiple processes include lower overhead for creation and context switching, reduced communication overhead, easier handling of asynchronous events, and greater parallelism.

Key Idea: Multi-threading improves efficiency and responsiveness by enabling lightweight concurrency and easier inter-thread communication within a single process.

Threads

• A thread is a concurrent execution path within a process.
• Threads in the same process can share global data as easily as functions within a program.
• Threads can run concurrently and must synchronize access to shared resources to avoid conflicts.
• Thread switching is more economical than process switching due to less state information being saved.

Key Idea: Threads enable lightweight concurrency within a process, allowing efficient execution and shared data access with minimal switching overhead.

This diagram contrasts the memory layout of a traditional single-threaded process with that of a multi-threaded process. On the left, a standard process is a single, self-contained unit of execution with its own code, data, heap, and a single stack. On the right, the multi-threaded process acts as a container for multiple threads. These threads are lightweight because they all share the process’s Code Segment, Data Segment, and Heap, allowing them to collaborate on the same data efficiently. However, to execute independently, each thread maintains its own private execution context, including its own Thread State (program counter, registers) and a separate Stack for its local variables and function calls.

Thread Implementation

• Threads can be implemented by the operating system or provided via thread libraries.
• User-Level Threads (ULT) are managed entirely in user space by thread libraries.
• Kernel-Level Threads (KLT) are managed by the operating system or libraries, such as POSIX P-threads.

Key Idea: Thread implementation can occur at the user or kernel level, influencing management, performance, and system interaction.

Basic Thread Types for User Processes

Kernel-Level Threads (KLT)

• Created and scheduled by the kernel (OS) independently, similar to processes.
• One thread blocking does not stop other threads in the same process.
• Can run in parallel on different processors, allowing overlapping input and processing.
• More economical than processes for creation, termination, and switching.
• Do not have kernel privileges; cannot execute in kernel mode.

In short: KLT are OS-managed for scheduling and parallelism, but they inherit the privilege level of the process they belong to, which is usually user mode.

KLT enables true parallelism because the kernel can schedule threads independently on multiple processors, while ULT cannot, since the OS is unaware of individual threads.

User-Level Threads (ULT)

• Created by user processes via thread library functions, without OS system calls.
• OS perceives the process as single-threaded, so threads cannot be distributed on multiple processors or blocked individually.
• More efficient than kernel threads since no mode switches occur during creation or switching.
• Cannot run truly in parallel; if one thread blocks, the entire process blocks.

In short: ULTs are lightweight and efficient but rely on user-space management, making the OS unaware of individual threads and limiting parallel execution.

ULTs offer high efficiency and lightweight management, while KLTs enable true parallelism and independent scheduling on multiprocessor systems.

Key Idea: Kernel threads allow true parallelism and independent scheduling, while user threads offer lightweight, efficient concurrency but rely on a single-threaded OS perspective.

Implementing KLT and ULT

• Kernel-Level Threads (KLT): Created and scheduled by the kernel; the OS handles mode switches and independent execution.
• User-Level Threads (ULT): Created via user-level library functions; scheduling handled by the application, with no mode switches.
• Comparisons:
  - Mode switches: KLT vs function calls: ULT
  - Scheduling: OS (KLT) vs application (ULT)
  - Execution: Multiple independently executable threads (KLT) vs single-threaded process perspective (ULT)
• Hybrid Threads: Combine the benefits of KLT and ULT, providing fast user-level management plus kernel-level scheduling and access.

Key Idea: KLTs offer parallelism and OS-level control, ULTs provide lightweight efficiency, and hybrid threads aim to balance speed, flexibility, and kernel access.

Threads — Summarized

• Multithreading allows a process to perform I/O and computation concurrently; one thread can block while others continue (KLT only).
• Multiprocessing with threads enables independent tasks to run on multiple processors in a shared-memory system (KLT only).
• Large applications can use cooperating threads instead of processes, reducing context-switch and creation overhead (ULT & KLT).
• Simplifies program development via divide-and-conquer approaches (ULT & KLT).
• Threads are more efficient than multiple processes.

Key Idea: Threads improve efficiency, parallelism, and program structure, with KLT enabling true concurrency on multiprocessors and ULT providing lightweight, low-overhead concurrency.

Examples of Threads

• Kernel-Level Threads (KLT): POSIX threads, Qthreads
• User-Level Threads (ULT): Default threads in Java and Python
• Wrappers / Hybrid Approaches: Non-default Java threads, OpenMP, OpenACC, and other libraries built on POSIX or similar threads

Key Idea: Different programming languages and libraries implement KLT, ULT, or hybrid threading to balance efficiency, parallelism, and flexibility.

Thread Variations

• Lightweight Processes (LWP): Hybrid threads used in Sun’s Solaris OS; combine ULT efficiency with kernel-level scheduling, similar to KLT.
• Scheduler Activations: Research-based approach to improve cooperation between user-level thread libraries and the kernel scheduler, reducing blocking issues.
• CILK: Research-focused runtime and language for parallel programming, emphasizing efficient multithreading and work-stealing scheduling.

Key Idea: Thread variations explore trade-offs between efficiency, parallelism, and scheduling flexibility, with hybrid and research approaches aiming to combine the benefits of ULT and KLT.

Hybrid Threads — Lightweight Processes (LWP)

• LWP behaves like a kernel-level thread; the kernel can create multiple LWPs per process via system calls.
• User-level thread libraries create threads within the process.
• The OS schedules LWPs, while the ULT scheduler selects which thread runs on each LWP.
• If a thread performs a blocking system call, the OS can either schedule another LWP or let the existing LWP continue, in which case the ULT scheduler picks another thread to run.

Key Idea: LWPs combine kernel-level scheduling with user-level thread management, allowing efficient multithreading while handling blocking and enabling parallelism.

Hybrid Threads — LWP

• Solaris OS uses a hybrid threading approach with processes containing LWPs (scheduled by the OS) and user-level threads (1 per LWP, scheduled by the process).
• The OS is aware of LWPs but not of the user-level threads.
• Solaris was developed by SUN Microsystems for its hardware, later owned by Oracle.
• Initially a proprietary UNIX system, Solaris evolved through the unification of several UNIX versions by SUN and AT&T as UNIX_SVR4

Key Idea: Solaris demonstrates hybrid threading by combining kernel-scheduled LWPs with user-level threads, providing both parallelism and efficient thread management.

Advantages of the Hybrid Thread Approach

• Most thread operations — creation, scheduling, destruction, and synchronization — are handled at the user level, reducing overhead.
• Blocking system calls does not block the entire process.
• LWPs can run in parallel on separate processors in a multiprocessor system.

Key Idea: Hybrid threads combine user-level efficiency with kernel-level parallelism, enabling fast thread management and true concurrent execution on multiprocessors.

Scheduler Activations

• Combines the benefits of user-level and kernel-level threads.
• When a thread blocks on a system call, the kernel performs an upcall to a user-space thread scheduler, which selects another runnable thread.
• Implemented in some Linux versions.
• Conceptually violates layered software principles by tightly coupling user-level and kernel-level scheduling.

Key Idea: Scheduler activations enable efficient thread management by coordinating kernel and user-level scheduling, allowing blocked threads to yield execution without stalling the process.

Threads in Distributed Systems

• Threads are powerful because they share an address space within a process.
• In distributed systems, memory is not shared across nodes, so threads cannot directly share data between nodes.
• Multithreading can still improve the performance of individual nodes by enabling concurrent execution within each node.

Key Idea: While threads cannot share memory across distributed nodes, they enhance local node performance through concurrency and parallelism.

Multithreaded Clients

• Main advantage: hides network latency in wide-area networks (WAN).
• Multiple threads perform independent tasks, e.g., one downloads text while others download images or figures.
• Allows the browser or client application to display content progressively as it arrives, improving responsiveness.

Key Idea: Multithreaded clients improve user experience by overlapping network communication with local processing, effectively hiding latency.

Multithreaded Clients (Enhanced)

• When servers are replicated, client threads can connect to different sites, downloading data in parallel streams.
• Designate a thread for each incoming data stream to handle and display it independently.
• This approach further improves performance and responsiveness by maximizing parallelism.

Key Idea: Using multiple threads with replicated servers allows parallel data retrieval and display, significantly reducing latency and enhancing client performance.

Multithreaded Servers

This diagram illustrates a common and efficient design for a multithreaded server known as the dispatcher-worker model. In this architecture, a single dispatcher thread’s only job is to listen for and accept incoming requests from the network. Instead of processing the request itself, the dispatcher immediately hands it off to one of several available worker threads from a thread pool. This division of labor is highly effective because the dispatcher remains lightweight and can quickly return to listening for new connections, ensuring the server is always responsive. Meanwhile, the worker threads handle the potentially time-consuming task of processing the requests concurrently, which significantly improves the server’s overall throughput and ability to handle many clients at once.

• Improve performance and simplify server structure by handling multiple requests concurrently.
• Typical server workflow: wait for request → execute request (may involve blocking I/O) → send reply.
• Server programming models: single-threaded, multi-threaded, or finite-state machine.
• Single-threaded servers handle one request at a time; other requests wait.
• Forking a new process per request is possible but inefficient due to inter-process communication overhead.
• Creating a new server thread is faster, as threads can access shared data structures without costly context switches.

Key Idea: Multithreaded servers enhance performance and responsiveness by using threads to handle multiple requests concurrently while efficiently sharing data.

Multi-Threaded Servers: Finite-State Machine Model

• Single-threaded server that avoids blocking on I/O by saving the state of the current request and switching to another task.
• Operation outline:
  - Receive request and process until blocking I/O is required.
  - Save current request state, start I/O, and handle the next task.
  - If a task completes I/O, resume it; otherwise, service a new request.
• Essentially achieves multiprocessing behavior, but managed within the server rather than by the OS.

Key Idea: The finite-state machine model allows single-threaded servers to handle multiple tasks concurrently without OS-level threads, simulating parallelism through careful state management.

Virtualization

• Multiprogrammed operating systems create the illusion of simultaneous execution using resource virtualization.
• Software makes multiple processes appear to execute concurrently, even on a single processor.
• Virtual machine technology creates separate virtual machines, each simulating the underlying hardware.
• A detailed discussion of virtualization will be covered in a subsequent lecture.

Key Idea: Virtualization enables multiple processes or systems to run concurrently on the same hardware by abstracting and emulating resources.

Client-Side Software

• Manages the user interface and may handle parts of processing and data.
• Provides distribution transparency: hides underlying network and system details from the user.
• Access transparency: RPC client-side stubs conceal communication and hardware specifics.
• Location, migration, and relocation transparency: achieved using naming systems and other techniques.
• Failure transparency: client middleware can retry connections to servers to handle failures.

Key Idea: Client-side software simplifies interaction with distributed systems by hiding complexity, providing transparency, and handling failures gracefully.

Client-Side Software for Replication Transparency

This diagram illustrates a method for achieving fault tolerance and data consistency in a distributed system through client-side request replication. In this model, the responsibility for duplicating a request is placed on the client machine itself. When the client application needs to perform an operation, it sends the same replicated request simultaneously to multiple independent servers. This ensures that even if one or more servers fail to respond, the operation can still be successfully processed by the others, increasing the system’s overall reliability.

• Shield the client application from replication complexities.
• Converts a single client request into multiple requests sent to replicated servers.
• Combines multiple responses from servers into a single response for the client.

Key Idea: Client-side software ensures replication transparency by managing multiple server interactions and presenting a unified response to the application.

More About Servers

• Servers are processes that provide services to a collection of clients.
• Passive servers: wait for requests to arrive before acting.
• Server design:
  - Iterative servers: handle one request at a time and return a response.
  - Concurrent servers: receive requests centrally and distribute them to separate threads or processes.
• Multithreaded servers are generally more efficient than forking a new process for each request.

Key Idea: Server design balances simplicity and concurrency, with multithreading offering efficient handling of multiple client requests compared to process-based approaches.

Connecting to a Server

• Client requests are sent to a communication endpoint called a port.
• A complete address of a process combines the port number and the server machine’s network address.
• Some port numbers are globally assigned, e.g., 21 for FTP, 80 for HTTP.
• VNC (Virtual Network Computing): allows remote access and control of graphical desktops over a network.

Key Idea: Connecting to a server relies on port numbers and network addresses to identify processes, enabling standardized communication and remote access.

Stateful versus Stateless Servers

• Stateless servers: do not retain client information between requests.
  - Example: web servers handling HTTP requests need not remember past client interactions.
• Stateful servers: retain information about clients and their current state.
  - Example: a file server tracks which process has opened a file and the next read position.
• Server crashes in stateful systems result in lost client state and uncertainty about request completion.

Key Idea: Stateless servers are simpler and more resilient, while stateful servers maintain client context but require mechanisms to handle failures and state recovery.

Server Clusters

• A server cluster is a networked collection of machines, each running one or more services.
• Clusters are often deployed on a LAN for efficiency and low-latency communication.
• A three-tiered structure is common for organizing services.
• Client requests are routed to one of the servers via a front-end switch.

Key Idea: Server clusters improve performance, scalability, and availability by distributing services across multiple machines and managing client requests through a front-end switch.

Types of Server Clusters

• Load Balancing: All servers provide the same services; client requests are distributed evenly to optimize performance.
• Failover: Backup servers monitor primary servers and take over if a failure occurs, ensuring reliability.
• High-Performance Computing (HPC): Processing is distributed across multiple nodes to accelerate computation; early examples include Beowulf clusters.

Key Idea: Different cluster types optimize for performance, reliability, or computational power by distributing workload and providing redundancy across multiple servers.

Three-Tiered Server Cluster

This diagram illustrates a classic three-tier architecture, a common design for scalable distributed systems. The first tier, or presentation tier, is represented by a logical switch that acts as a load balancer, receiving all incoming client requests and dispatching them to the next layer. The second tier is the application or logic tier, composed of multiple compute servers that execute the application’s business logic to process the dispatched requests. Finally, the third tier is the data tier, consisting of a distributed file or database system that stores and manages the persistent data, handling all data access requests from the application tier. This separation of concerns allows each tier to be developed, managed, and scaled independently, creating a robust and flexible system.

• Tier 1: Front-end switch, provides access and replication transparency.
• Tier 2: Application servers; may include compute-intensive machines for data processing.
• Tier 3: Data-processing servers, such as file servers and database servers, often handle the bulk of the workload.

Key Idea: A three-tiered cluster separates access, application processing, and data management to optimize performance, scalability, and transparency.

Server Clusters

• Some clusters run identical services on all machines, benefiting from load balancing.
• Other clusters have different machines providing different services, benefiting from server migration to idle machines.
• The performance of server clusters can be enhanced by using virtual machines to optimize resource utilization.

Key Idea: Server clusters improve performance and flexibility through load balancing, service migration, and virtualization, adapting to workload and resource availability.

Code Migration: Overview

• Instead of passing data in distributed systems, code can be migrated to remote nodes.
• Benefits include: load balancing, reduced communication overhead, increased parallelism (e.g., mobile agents for web searches), and flexible system architecture configuration.
• Code migration vs. process migration: Process migration involves moving the entire process state, which may incur high overhead.
• Early distributed systems like NOW and HTCondor focused on process migration, aiming to provide it transparently.

Key Idea: Code migration enhances flexibility, parallelism, and efficiency in distributed systems, offering an alternative to the heavier overhead of full process migration.

Client-Server Examples of Code Migration

• Example 1: Send Client Code to Server
  - When a client needs to perform many database operations (e.g., data mining), it can be efficient to ship part of the client application to the server.
  - Only the results are sent across the network, reducing communication overhead.
• Example 2: Send Server Code to Client
  - In interactive database applications, clients fill forms that translate into multiple DB operations.
  - Sending server-side code to the client reduces network traffic and improves service responsiveness.

Key Idea: Code migration in client-server systems optimizes performance and network usage by moving computation to where it is most efficient — either client or server.

The diagram shows executable code being transferred from one system (the code repository) to another (the client) to be run. This is the definition of code migration. In this particular model, the client actively initiates the transfer by fetching the code it needs. This is different from other migration types, where a server might push code to a client or where an entire running process (code and state) moves to another machine. The process begins when the client, instead of having pre-installed logic, first contacts a code repository to fetch service-specific client-side code (Step 1). Once this code is downloaded and executed, the client is dynamically equipped with the necessary protocols and functionality to communicate directly with the server to access its services (Step 2). This “code-on-demand” approach allows for a lightweight and extensible client that can adapt to various servers without requiring prior installation of specific software.

Examples of Code Migration

• Mobile Agents: Independent code modules that migrate between network nodes and interact with local hosts, e.g., performing parallel searches across multiple sites.
• Dynamic Configuration of Distributed Systems: Client-side software can be downloaded dynamically from the server when needed, instead of being pre-installed.
• Load Balancing: Can be achieved via either code migration or process migration to distribute workload efficiently.

Key Idea: Code migration enables flexible, dynamic, and parallel execution in distributed systems, supporting mobile agents, on-demand software deployment, and load balancing.

Issues for Code Migration

• Heterogeneous Systems: Target machines may have different architectures or operating systems; code may need recompilation or adaptation.
• Resource Migration: Consider whether associated resources like files, databases, or printers need to move with the code.
• Security: Protect both the host machine and the migrated code from unauthorized access or malicious actions.
• Previous distributed systems (e.g., Condor) have addressed these challenges.

Key Idea: Effective code migration requires handling system heterogeneity, resource availability, and security to ensure correct and safe execution across distributed nodes.

A Model for Code Migration (Fuggetta et al., 1998)

• Process Components:
  - Code Segment: Executable instructions of the process.
  - Resource Segment: References to external resources like files, printers, or other processes.
  - Execution Segment: Current state, including private data, stack, program counter, registers, etc. The same information is saved during a context switch.
• Virtual Memory Considerations: Must determine how memory pages and mappings are transferred or re-established on the target system to maintain execution correctness.

Key Idea: Code migration requires careful handling of a process’s code, resources, and execution state, including virtual memory management, to ensure correct and efficient execution on a remote node.

A Model for Code Migration (2)

• Weak Mobility: Transfers the code segment and possibly some initialization data.
  - Migration occurs before execution begins or at limited intermediate points.
  - Requires portable code.
  - Example: Java applets.
• Strong Mobility: Transfers both the code segment and execution segment (full process migration).
  - Processes can migrate after execution has started.
  - More complex due to the need to preserve execution state.

Key Idea: Weak mobility moves only code and initial data, suitable for pre-execution tasks, while strong mobility enables full process migration, including active execution state, offering greater flexibility but higher complexity.

A Model for Code Migration (3)

• Sender-Initiated: Migration is initiated by the code’s “home” location.
  - Examples: uploading code to a compute server, launching a mobile agent, sending code to a database.
• Receiver-Initiated: Migration is initiated by the host machine that downloads code to execute locally.
  - Examples: applets, downloading client code.
• Load Balancing Implications:
  - Sender-initiated: busy sites offload work to others.
  - Receiver-initiated: idle machines volunteer to take on excess work.

Key Idea: Code migration can be initiated by either the sender or receiver, enabling flexible strategies for computation distribution and load balancing in distributed systems.

Security in Code Migration

• Remotely executing code may access host resources, so trust is essential.
• Example: Uploaded code should not be able to corrupt server disks.
• Hosts can restrict access to sensitive local resources.
• Guest processes should execute in a sandbox to limit potential harm.

Key Idea: Security in code migration relies on sandboxing and controlled access to ensure that remote code cannot compromise host systems or resources.

Resource Migration

• Resources are bound to processes in three ways:
  - By Identifier: Specific object reference, e.g., URL, IP address, local port number.
  - By Value: Reference to a resource that can be replaced with another of the same value, e.g., standard library.
  - By Type: Reference by resource type, e.g., a printer or monitor.
• Code migration must preserve the binding of processes to resources and not weaken these associations.

Key Idea: Effective resource migration ensures that process-resource bindings remain intact, maintaining correct execution and system behavior after code migration.

Resource Migration in a Cluster

• Local resource bindings are easier to manage when all machines are on the same LAN.
• Clients must be notified of new addresses after migration.
• If data storage resides in a third tier, migrating file bindings is straightforward.

Key Idea: In clustered systems, resource migration is simplified by LAN proximity and tiered architectures, allowing efficient reassignment of resources without disrupting client access.

Migration and Local Resources

This diagram is a decision matrix that outlines the best strategies for managing a process’s access to local resources when it’s migrated to a new machine. It considers two key factors: how the process is bound to the resource (e.g., needing a specific file vs. any printer) and how the resource is bound to the machine (e.g., an easy-to-move file vs. a fixed hardware port). Based on these conditions, the table recommends the optimal action: Move (MV) the resource with the process, Copy (CP) its value, Rebind (RB) to a similar local resource on the new machine, or establish a Global Reference (GR) to access the original resource remotely over the network.

• Core problem: When a process migrates, its connections to files, devices, or data on the original machine must be handled appropriately.
• Process-to-resource binding:
  - By Identifier: Requires a specific resource (e.g., exact file).
  - By Value: Needs only the content, not the resource itself (e.g., a number stored in a file).
  - By Type: Needs any resource of a certain kind (e.g., any available printer).
• Resource-to-machine binding:
  - Unattached: Easy to move (e.g., data file).
  - Fastened: Difficult but possible to move (e.g., local database).
  - Fixed: Cannot be moved (e.g., physical hardware port).
• Strategies for migration:
  - GR (Global Reference): Access the resource remotely over the network (used for fixed resources referenced by identifier).
  - MV (Move): Move the resource to the new machine (ideal for unattached resources).
  - CP (Copy): Copy just the value of the resource (used when the process needs only the data).
  - RB (Rebind): Connect to an equivalent local resource on the new machine (used for type-based references).

Key Idea: Resource handling during process migration depends on how a process binds to a resource and how fixed the resource is, with strategies including global access, moving, copying, or rebinding.

Migration in Heterogeneous Systems

• Migrated object code may be incompatible across different computers and operating systems.
• Solutions include process virtual machines (e.g., JVM):
• Directly interpret migrated source code at the host (like scripting languages).
• Interpret intermediate code (object code for a virtual machine) generated by a compiler.

Key Idea: Heterogeneous system migration is enabled by virtual machines or interpreters, allowing code to run correctly on diverse hardware and operating systems.

Migrating Virtual Machines

• A virtual machine (VM) encapsulates an entire computing environment, including code, data, and resources.
• Properly implemented VMs provide strong mobility, as local resources can migrate with the environment.
• Migration involves “freezing” the environment (temporarily stopping processes) and transferring the entire state to another machine.
• Example: In a server cluster, VM migration supports maintenance tasks such as replacing or upgrading machines without downtime.

Key Idea: Migrating virtual machines enables seamless transfer of complete computing environments, preserving execution state and resources for flexibility and maintainability in distributed systems.

🔙 Back to all notes
𝕏 Let’s Connect

Get Prajun Trital’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Backlinks:
Advanced Operating System