Add RwLock to embassy-sync

[AlixANNERAUD]

Fixes #1394

The implementation is very similar to Mutex

[lulf]

Thanks for the PR! I have some question specifically around the critical section raw rw lock, which I don't understand how can work in a single executor.

[lulf]

Won't spinning effectively prevent this to be used within the same executor as it would deadlock here? Same in the lock_write().

[AlixANNERAUD]

Indeed, my initial approach wasn’t ideal. I completely refactored it by using a Mutex as a locking mechanism for the inner state and adhered to the same overall pattern as Mutex.

[mschnell1]

This still seems open.
I supposedly would like to use it some day soon. Are there any severe problems ?

[lulf]

Could you give an example for needing to use the map()? Won't

let g = lock.read().await;
do_stuff(g.deref());

allow you to 'calling methods on the contents of the RwLockReadGuard without moving out of the guard' as stated in the comment?

[mschnell1]

To manage the rather complex state of an embedded device I drafted this code:

    #[derive(Debug, Default, Clone)]
    pub struct DisplayState {
       ...
    }

    use crate::api::api::RwLock;  // switching std / embassy
    use lazy_static::lazy_static;
    lazy_static! {
        static ref DISPLAY_STATE: RwLock<DisplayState> = RwLock::new(DisplayState::default());
    }

    pub fn global_check_display_field(a: &DisplayField) -> bool {
        let ds = DISPLAY_STATE.read().unwrap();
        ds.check_display_field(a)
    }

    impl PartialEq for DisplayField {
        fn eq(&self, other: &Self) -> bool {
            if !(self.content == other.content) {
                return false;
            };
            if !global_check_display_field(self) || !global_check_display_field(other) {
                return false;
            }
            true
        }
    }

The many information sections in DISPLAY_STATE can be read by certain "threads" of the firmware and written by others. hence RwLock seemed the way to go.

Right now I don't see the necessity of using more than the.read()and .write() functions.

[AlixANNERAUD]

I've just transposed the mutex pattern to RwLock for consistency but I can remove map guard if it is not necessary.

[mschnell1]

Thanks a lot
looking forward to the release....

[lulf]

I've just transposed the mutex pattern to RwLock for consistency but I can remove map guard if it is not necessary.

Yeah, please remove it. If there is a use case for it, it can be added later.