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

New Issue

muellerr · 2020-06-01T18:36:33+02:00

muellerr commented

2020-06-01 18:36:33 +02:00

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

muellerr referenced a pull request that will close this issue

2020-12-01 15:30:48 +01:00

Local Data Pool Init #280

gaisser closed this issue

2020-12-08 15:34:30 +01:00

gaisser commented

2020-12-08 15:36:07 +01:00

Merged as part of #280

Sign in to join this conversation.