Skip to content

Program deadlocks depending on name of scoped thread #20995

@burtonageo

Description

@burtonageo

I've been using rust to learn about threading using the Little Book of Semaphores. I'm currently on Exercise 3.2 (page 12), and I've encountered an unintuitive phenomenon where my program deadlocks depending on what I've named my thread in its let binding. The program is shown below (link to rust playpen), and the relevant lines are 29 and 30 (let s_b2 =…).

use std::sync::{Arc, Semaphore};
use std::thread::Thread;

// Our functions. a1 and b1, and a2 and b2
// can happen concurrently, but a1 must happen
// before b2 and b1 must happen before a2
fn statement_a1() { println!("a1"); }
fn statement_a2() { println!("a2"); }

fn statement_b1() { println!("b1"); }
fn statement_b2() { println!("b2"); }

#[allow(unstable)]
fn main() {

    // We use 2 semaphores here: sem_a to signal that
    // statement_a2 can safely run, and sem_b to signal
    // that statement_b2 can safely run
    let sem_a = Arc::new(Semaphore::new(0));
    let sem_b = Arc::new(Semaphore::new(0));

    let s_a1 = sem_a.clone();
    let _ = Thread::scoped(move || {
        statement_a1();
        s_a1.release();
    });

    let s_b2 = sem_b.clone();
    // Rename this thread to _, and the program deadlocks
    let _t = Thread::scoped(move || {
        s_b2.acquire();
        statement_a2();
    });

    let s_b1 = sem_b.clone();
    let _ = Thread::scoped(move || {
        statement_b1();
        s_b1.release();
    });

    let s_a2 = sem_a.clone();
    let _ = Thread::scoped(move || {
        s_a2.acquire();
        statement_b2();
    });
}

My rust version on my local machine is rustc 1.0.0-dev (d2d35db 2015-01-11 06:55:33 +0000), and I use OSX.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions