tokio::sync::Lock hangs and futures_locks::RwLock panics on a locked structure

This bug has been haunting me for a week. This question is previously posted in Stackoverflow. However, no one actually read it and therefore I came here with some developments I discovered these days.

Hi everyone:

So I've been trying to write a Lock over a vector to provided async read/write for multiple threads. The idea is to use tokio::run and then tokio::spawn a bunch of async threads that tries to lock a futures_locks::RwLock<Vec<Seed>> and then get(k: SeedId) or push(s: Seed). The sequence and behavior of these threads are hard-coded in main function.

If the index is not present yet, the thread will return Async::NotReady and push this task to parked list.
If a data is pushed, it checks if there are any thread in the parked list that wants this data and notify() them.

However, the program may panic when a reader/writer attempts to drop the lock. According to, when a thread is dropping the lock, it will mpsc::Sender::send(()) to the next one in line to notify them that the lock is ready to use. However, in seed-store, send(()) failed because the receiver is dropped. This caused all the following threads to panic as the lock is then poisoned.

Something that I have tried:
Remove notify feature
Done in a new branch. Now when the Seed is not available yet, the thread will return a dummy Seed. But the problem is still there, so it's not this feature's problem.

Change to futures-locks::Mutex
Tried. Won't work. Panics on send(()), almost the same with RwLock.

Change to tokio-lock::Lock
Tried. Won't work. Some threads still hangs(without panic).
The above two changes combined made me believe that there are some code logic bugs that I can't tell.

Change to tokio::runtime::current_thread
(Partially) worked. File::create will fail and no file will be dumped. Also, current_thread won't use a thread pool(therefore it doesn't have a poison problem), this hurts performance.

I have posted these code here. Sorry I can't post a link to the playground so you can run it directly, I can't use futures_lock in the playground.

So basically the issue is that the next future in queue for the lock had been dropped, so the channel fails?

Yes. But it shouldn't since I didn't even touch that channel as it is abstracted in the futures_locks... right?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.