【求助】select! 内使用 tokio::sync::Mutex导致死锁的问题
💡
原文中文，约1300字，阅读约需4分钟。
📝
内容提要
文章讨论了使用Tokio库处理SOCKET读写的任务队列。通过两个线程分别处理读写，使用select!进行管理。当SOCKET断开时，读线程先结束，写线程被取消，但Mutex Lock未释放，导致后续调用出现死锁问题。
🎯
关键要点
- 使用tokio::sync::mpsc::channel创建任务队列，receiver用Arc和Mutex包装。
- SOCKET读写分离后，启动两个线程分别处理读和写任务。
- 读写线程通过select!进行管理。
- 当SOCKET断开时，读线程先结束，写线程被取消，但Mutex Lock未释放。
- 再次调用Mutex.lock.await时会导致死锁问题。
❓
延伸问答
如何使用Tokio库处理SOCKET读写任务队列？
可以使用tokio::sync::mpsc::channel创建任务队列，并用Arc和Mutex包装receiver，启动两个线程分别处理读和写任务。
在使用select!时可能遇到什么问题？
当SOCKET断开时，读线程先结束，写线程被取消，但Mutex Lock未释放，可能导致后续调用出现死锁问题。
为什么Mutex Lock会导致死锁？
在SOCKET断开后，写线程的Mutex Lock未被释放，再次调用Mutex.lock.await时会导致死锁。
如何避免Tokio中的死锁问题？
确保在SOCKET断开时正确释放Mutex Lock，或者在设计中避免在取消线程时持有锁。
Tokio的任务队列是如何工作的？
Tokio的任务队列通过mpsc::channel创建，允许多个任务通过receiver进行异步通信，支持并发处理。
在Tokio中如何管理读写线程？
可以使用select!来同时管理读线程和写线程，确保它们能够并发执行并处理SOCKET数据。
➡️
