I am developing a Rust application where I have a BusDevice that interacts with a PacketManager. I am experiencing a deadlock when trying to lock a Mutex in a multi-threaded environment. The application gets stuck at the line where the Mutex is locked, and it never proceeds further.

Detailed Description:

In my Rust application, I have a BusDevice that sends acknowledgment packets using a PacketManager. The send_ack method in BusDevice spawns a new thread to handle the acknowledgment, but it seems to hang when trying to acquire the lock on the PacketManager’s Mutex.

Here is the relevant part of my BusDevice implementation:

use std::sync::{Arc, Mutex};

pub struct BusDevice {
    packet_manager: Arc<Mutex<PacketManager>>,
    // other fields...
}

impl BusDevice {
    pub fn send_ack(&self, dest: u8, seq: u8) {
        let packet_manager = Arc::clone(&self.packet_manager);

        std::thread::spawn(move || {
            let pm = packet_manager.lock();
            match pm {
                Ok(mut pm) => {
                    pm.send_ack(0, dest, seq);
                }
                Err(e) => {
                    println!("Failed to lock PacketManager: {:?}", e);
                }
            }
        })
        .join()
        .expect("Thread join failed");
    }
}

And the PacketManager has the following structure:

use std::sync::{Arc, Mutex};
use serialport::TTYPort;

pub struct PacketManager {
    serial_port: Arc<Mutex<TTYPort>>,
    // other fields...
}

impl PacketManager {
    pub fn send_ack(&mut self, src: u8, dest: u8, seq: u8) {
        // Logic to send acknowledgment packet
    }
}

What I Have Tried:

I have ensured that no other parts of the code hold the lock for an extended period.
I have simplified the send_ack method to isolate the problem, but the issue persists.
I added print statements to trace the execution, and it confirms that the application gets stuck at packet_manager.lock().

Expected Behavior:

The spawned thread should acquire the lock on the PacketManager, send the acknowledgment packet, and then release the lock without causing a deadlock.