Quartz 4

ASP Sample Past Paper

9 min read

SAMPLE PAPER

1b)

Question

Answer

State Machines in Rust: The Type-State Pattern

State machines can be elegantly represented in Rust using the “type-state pattern,” which leverages the type system to encode states as distinct types, ensuring operations are only available in appropriate states at compile time.

Implementation Approach

The core idea is to represent each state as a separate type parameter or distinct type, with state transitions represented as methods that consume one state and return another:

// A TCP connection state machine
struct TcpConnection<S\> {
    socket: Socket,
    address: SocketAddr,
    state: S,
}
 
// Define state types
struct Closed;
struct Listening;
struct Connected;
 
impl TcpConnection<Closed\> {
    fn new(address: SocketAddr) -> Self {
        TcpConnection {
            socket: Socket::new(),
            address,
            state: Closed,
        }
    }
    
    fn listen(self) -> TcpConnection<Listening\> {
        // Set up listening socket
        TcpConnection {
            socket: self.socket,
            address: self.address,
            state: Listening,
        }
    }
}
 
impl TcpConnection<Listening\> {
    fn accept(self) -> TcpConnection<Connected\> {
        // Accept connection
        TcpConnection {
            socket: self.socket,
            address: self.address,
            state: Connected,
        }
    }
    
    fn close(self) -> TcpConnection<Closed\> {
        // Close the listening socket
        TcpConnection {
            socket: self.socket,
            address: self.address, 
            state: Closed,
        }
    }
}
 
impl TcpConnection<Connected\> {
    fn send_data(&mut self, data: &[u8]) -> Result<(), Error> {
        // Send data on connected socket
        // Note: this doesn't change state
        Ok(())
    }
    
    fn close(self) -> TcpConnection<Closed\> {
        // Close the connection
        TcpConnection {
            socket: self.socket,
            address: self.address,
            state: Closed,
        }
    }
}

Advantages

  1. Compile-time state validation: Invalid state transitions are caught at compile time. For example, attempting connection.send_data() on a TcpConnection<Closed> would fail to compile.

  2. Self-documenting: The API makes valid operations for each state explicit. Developers can only see the methods available for the current state.

  3. Zero runtime overhead: State enforcement has no runtime cost since it’s enforced by the type system.

  4. Ownership guarantees safety: State transitions typically consume self, ensuring the old state cannot be used after a transition occurs.

  5. Refinement through traits: States can implement common traits for shared behaviors while maintaining state-specific operations.

trait Connection {
    fn get_address(&self) -> SocketAddr;
}
 
impl<S\> Connection for TcpConnection<S\> {
    fn get_address(&self) -> SocketAddr {
        self.address
    }
}

Disadvantages

  1. Code duplication: Similar functionality across states may require repetition or complex trait abstractions.

  2. Type complexity: With many states or transitions, type signatures can become verbose and complex.

  3. Dynamic state transitions: For state machines where transitions depend on runtime values, this approach can be cumbersome:

// Difficult to represent runtime-determined transitions
fn process_event(self, event: Event) -> ??? {
    // What return type? Cannot return different types based on runtime values
}

  1. Persistence challenges: Serializing/deserializing type-state machines requires additional work since the state is encoded in the type, not just the data.

  2. Increased binary size: Type specialization can lead to code bloat as each state’s implementation generates separate machine code.

Alternative approaches exist, such as the enum-based state pattern which trades compile-time enforcement for dynamic flexibility:

enum State {
    Closed,
    Listening,
    Connected,
}
 
struct TcpConnection {
    socket: Socket,
    address: SocketAddr,
    state: State,
}
 
impl TcpConnection {
    fn send_data(&mut self, data: &[u8]) -> Result<(), Error> {
        match self.state {
            State::Connected => {
                // Send data
                Ok(())
            }
            _ => Err(Error::InvalidState),
        }
    }
}

The type-state pattern provides exceptional safety guarantees at the cost of some flexibility and verbosity, making it particularly suitable for critical systems where correctness is paramount.

2c)

Question

Solution: The benefits of switching to a memory safe language are clear: there will be some reduction is memory-related security vulnerabilities and a general improvement in software correctness [2 marks]. The costs are less clearly defined. Up to [5 marks] are available for discussion of the overheads of memory safety, limitations of designs that can be expressed in safe languages, compatibility of the new safe language and unsafe prior code, and so forth. There is no single correct answer, and marks are assigned for reasoned discussion with technical justification. Up to [3 marks] are available for discussion of what is stopping the industry from moving entirely to memory safe languages. The discussion likely focus on compatibility, training costs, inertia, and so on. Any reasoned and well justified answer is accepted.

Answer

Memory Safety in Systems Programming: Feasibility Analysis

Using exclusively memory-safe languages for systems programming is increasingly feasible but not yet universally practical. The landscape has evolved significantly with languages like Rust, but complete industry transition faces substantial obstacles.

Benefits of Memory-Safe Languages

Security improvements: Memory safety eliminates entire vulnerability classes including buffer overflows, use-after-free, and dangling pointer vulnerabilities that constitute roughly 70% of critical CVEs in systems like operating systems, browsers, and embedded devices.

Developer productivity: Developers spend less time debugging memory corruption issues, which are notoriously difficult to reproduce and diagnose. Memory-safe languages provide better guarantees and earlier detection of issues.

Maintenance benefits: As codebases age, memory safety becomes increasingly valuable by preventing subtle regressions when modifying complex, memory-sensitive code.

Costs and Challenges

Performance overhead: Memory-safe mechanisms introduce varying degrees of overhead:

  • Garbage collection can introduce unpredictable pauses and memory usage patterns
  • Reference counting (as in Swift) adds atomic operations on every reference manipulation
  • Borrow checking (as in Rust) has zero runtime cost but introduces compile-time complexity

Low-level hardware access: Systems programming often requires direct manipulation of hardware registers, memory-mapped I/O, and precise memory layout control. Memory-safe languages typically restrict these operations to maintain their guarantees:

// In Rust, unsafe blocks are still needed for many systems operations
let memory_mapped_register = unsafe {
    *(0x4000_0000 as *mut u32)
};

Interoperability burden: Existing systems have millions of lines of unsafe C/C++ code. Any transition requires:

  • Foreign function interfaces to call legacy code safely
  • Gradual migration strategies that maintain binary compatibility
  • Translation of complex idioms that don’t map cleanly to safe paradigms

Implementation complexity: Memory-safe systems languages often introduce more complex type systems and ownership models that can be difficult to learn and apply correctly.

Industry Adoption Barriers

Legacy codebase inertia: Major systems (Linux kernel, Windows, embedded firmware) represent decades of investment in C/C++. The cost-benefit analysis of rewriting often doesn’t justify the massive effort required.

Developer expertise: The systems programming workforce is heavily trained in C/C++. Retraining at scale requires substantial investment and faces resistance from developers who have deeply internalized unsafe programming patterns.

Ecosystem maturity: Despite rapid growth, memory-safe systems languages still lag in:

  • Library availability for specialized domains
  • Tooling integration with existing build systems
  • Long-term stability guarantees needed for infrastructure with decades-long lifespans

Hardware-specific constraints: Some domains (microcontrollers, real-time systems) have extreme resource constraints or timing requirements that still favor leaner C implementations over the abstractions in memory-safe alternatives.

Current State of Feasibility

Memory-safe systems programming is most feasible for:

  • New projects without legacy compatibility requirements
  • Security-critical components where the safety benefits clearly outweigh transition costs
  • Domains with sufficient resources to absorb any performance overhead

Industry leaders are making incremental progress—Microsoft is investing in Rust for Windows components, Google is using it for Android, and the Linux kernel now accepts Rust modules. These strategic, partial adoptions represent a pragmatic middle ground that gradually improves safety while managing transition costs.

Full industry transition remains years away, but the direction is clear: memory safety is becoming increasingly feasible and will continue to expand in systems programming as languages mature and ecosystems grow.

3a)

Question

, while asynchronous I/O is performed in the background allowing the rest of the program to proceed concurrently [2 marks]. Asynchronous I/O is beneficial because I/O is slow, and waiting which it’s performed is inefficient [2 marks].

3b)

Question

Answer

Evaluating Coroutines and Futures for Asynchronous I/O

The coroutine-based model with Futures and await is a powerful approach to asynchronous programming that offers significant advantages over alternatives, though it comes with its own set of challenges.

Strengths

Intuitive code structure: The most compelling advantage is how coroutines allow developers to write asynchronous code that reads almost like synchronous code. This preserves the logical flow and reduces the cognitive overhead:

async fn process_request(request: Request) -> Result<Response\> {
    let user = database.get_user(request.user_id).await?;
    let permissions = auth_service.check_permissions(user).await?;
    let data = data_service.fetch_data(request.query, permissions).await?;
    Ok(Response::new(data))
}

Efficient resource utilization: Coroutines enable high concurrency without the overhead of thread-per-connection models. A single thread can manage thousands of coroutines, handling I/O-bound workloads efficiently.

Composability: Futures can be combined into higher-level abstractions. Operations like running futures in parallel, racing them, or chaining them together can be expressed clearly:

const [userData, analyticsData] = await Promise.all([
    fetchUserProfile(userId),
    fetchAnalytics(userId)
]);

Error handling: Many implementations integrate with the language’s native error handling mechanisms, allowing try/catch or Result types to work naturally across asynchronous boundaries.

Weaknesses

Hidden control flow: The await points introduce invisible context switches that can make debugging and reasoning about execution order more difficult. A function may begin execution on one thread and resume on another after an await.

Runtime complexity: Coroutine implementations require sophisticated runtime systems to manage the task scheduling and wakeup mechanisms. This introduces complexity that developers must understand when diagnosing performance issues.

Colored functions: The “async” nature of functions becomes part of their API contract, creating what’s known as “colored functions” - async functions can only be called from other async contexts, leading to contagious async annotations throughout the codebase.

Stack management challenges: Traditional debugging tools like stack traces become less useful as the logical flow jumps between different coroutines, making it harder to reconstruct the chain of operations that led to a failure.

Cancellation complexity: Properly handling cancellation of in-progress operations adds significant complexity, especially when resources need cleanup when operations are abandoned.

Assessment

Despite these challenges, coroutine-based asynchronous programming represents one of the best available models for managing concurrent I/O. Languages like Rust, Kotlin, JavaScript, and Python have adopted this approach because it strikes a good balance between performance and developer ergonomics.

The model is particularly effective for I/O-bound services like web servers and database clients where the primary challenge is managing many concurrent operations rather than CPU-intensive work. For such applications, the clarity of sequential-looking code combined with efficient resource utilization outweighs the added complexity of the runtime system.

The most successful implementations provide strong abstractions for common patterns (like streaming and backpressure) and robust tooling to help developers understand the async flow. With these supports in place, coroutines and futures provide an excellent foundation for modern asynchronous systems programming.

Graph View

Backlinks