RwLockWriteGuard read and write

I'm writing two tasks. They will send and receive messages from each other. Assume that one is the sender and the other is the receiver. Sender lock the RwLockWriteGuard<T> when it is sending messages(using the T)and then the task is blocked by my kernel(I use a function to block task). When the sender is blocked in my kernel, the receiver try to read but the RwLockWriteGuard<T> has been locked by the blocked task. How can I unlock the RwLockWriteGuard<T> before I use my function to block the task.

RwLockWriteGuard<T> is created by RwLock<T> using try_write() method

Lock is unlocked when the lock guard is dropped. You can drop it early with drop(guard) function. You should drop() the guard before calling send().

It's possible to have many read-only locks, but any lock with ability to write is always exclusive and always blocks everyone else.

However, I'm confused why do you use locks here. Usually sending is a replacement for locking, because it preserves single ownership/exclusive access across threads. You could send just T.

It sounds like you are storing the sender and receiver in the same place and behind the same lock. You shouldn't do that. The sender and receiver should be exclusively owned by the code sending and receiving respectively.

Sorry, I can't understand the meaning of the above quote?

I create two different tasks and get handler of them. Then, I will use one task as sender through the handler and one task as receiver. They share the RwLock<T>. But they execute different functions. One updating the T data(use write() method) and get blocked. Before the sender sends the message, it will notify the receiver. The receiver then will dequeue from the blocked queue and read data from T

At this point both me and Alice are confused about what your code is actually doing. You may have some custom solution that we haven't heard of.

Can you show your code? Or create an example on https://play.rust-lang.org?

The channels should not be stored inside an RwLock.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.