BaseFlash::state - use critical region to change
Posted: Mon Apr 17, 2023 7:20 pm
The BaseFlash:state should be able to be read without having to use flash(Acquire/Release)Exclusive in the case of multiple threads using the same BaseFlash. Normally, this isn't a problem - but erase operations can take a long time during which the thread managing the erase may want to get exclusive access to the BaseFlash device (by locking it with the mutex).
Since the BaseFlash::state variable is not modified in a critical region using osalSysLock/Unlock - the only way to safely check the state of the BaseFlash is to acquire the lock - which could end up with the thread getting stalled for a long duration (the duration of an erase). If critical region hygiene is maintained by the BaseFlash drivers using osalSysLock/Unlock to interact with the BaseFlash::state - then other threads can simply read the BaseFlash::state in a critical region and be guaranteed of no race condition.
It comes down to this - querying the state of the BaseFlash (or any module?) should be race-free and quick. There is a tradeoff. For example, you may only be able to see the state of the BaseFlash:state variable this way, and not actually query the device (such as what snor_query_erase would do). But that's better than waiting potentially 10s of seconds (a lifetime in microcontroller time) for feedback on what the state of the BaseFlash is.
Since the BaseFlash::state variable is not modified in a critical region using osalSysLock/Unlock - the only way to safely check the state of the BaseFlash is to acquire the lock - which could end up with the thread getting stalled for a long duration (the duration of an erase). If critical region hygiene is maintained by the BaseFlash drivers using osalSysLock/Unlock to interact with the BaseFlash::state - then other threads can simply read the BaseFlash::state in a critical region and be guaranteed of no race condition.
It comes down to this - querying the state of the BaseFlash (or any module?) should be race-free and quick. There is a tradeoff. For example, you may only be able to see the state of the BaseFlash:state variable this way, and not actually query the device (such as what snor_query_erase would do). But that's better than waiting potentially 10s of seconds (a lifetime in microcontroller time) for feedback on what the state of the BaseFlash is.