PoolVariableIF: make read() and commit() thread-safe and introduce lock-less calls #96
To increase flexibility of the code, I suggest following adaptions to the
commit() calls are renamed to
readWithoutLock(): Read without locking the data pool
commitWithoutLock(): Commit without locking the data pool
These functions are protected and should be called by handler classes like dataset. Documentation is there to hint the usage of dataset(s) to prevent unnecessary lock/unlock operations. The datasets use these calls and lock and unlock once (like before).
commit() calls should implement the locking mechanisms internally. They will lock and forward the call to the lockless functions (in all cases I have seen so far).
I also suggest passing a lock timeout value to those read functions which pass that value to their lock calls.
Right now, the lock call can block permanently (at least of linux, on freeRTOS they just poll and the call fails immediately for a blocked mutex). It would propably be better to limit that value to 50ms or some similar value.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?