PoolVariableIF: make read() and commit() thread-safe and introduce lock-less calls #96

Closed
opened 2020-06-01 18:36:33 +02:00 by muellerr · 1 comment
Owner

To increase flexibility of the code, I suggest following adaptions to the PoolVariableIF:

The old read() and 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).

The new read() and 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.

To increase flexibility of the code, I suggest following adaptions to the `PoolVariableIF`: The old `read()` and `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). The new `read()` and `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.
muellerr added the
feature
label 2020-06-01 18:36:41 +02:00
muellerr changed title from PoolVariableIF: make read() and commit() threaf-safe and introduce lock-less calls to PoolVariableIF: make read() and commit() thread-safe and introduce lock-less calls 2020-06-01 18:40:09 +02:00
Owner

Merged as part of #280

Merged as part of #280
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: fsfw/fsfw#96
No description provided.