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.
BaseFlash::state - use critical region to change
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: BaseFlash::state - use critical region to change
Hi,
Why acquire a lock just to read "state"? single read/write operations are atomic, no lock required.
Is there some read-modify-write to consider somewhere?
Giovanni
Why acquire a lock just to read "state"? single read/write operations are atomic, no lock required.
Is there some read-modify-write to consider somewhere?
Giovanni
Return to “Small Change Requests”
Who is online
Users browsing this forum: No registered users and 17 guests