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.

[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.

[Dirbaio]

lgtm other than @lulf 's feedback. please mark as ready for review when done.

[AlixANNERAUD]

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.

Done !

[AlixANNERAUD]

In addition, I was wondering if implementing a blocking version (like the blocking mutex) would be useful. I can do it if you'd like.

[Dirbaio]

thanks!