fsfw/fsfw
fsfw/fsfw
10
3
Fork 6
Code Issues 31 Pull Requests 4 Releases 10 Wiki Activity

Mutex improvements #90

Merged
gaisser merged 22 commits from KSat/fsfw:mueller_MutexImprovements into master 2020-08-25 12:13:30 +02:00
Conversation 6 Commits 22 Files Changed 16 +16 -3
2 changed files with 16 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit b5567e8aae - Show all commits

17
osal/rtems/Mutex.cpp
View File

@ -1,7 +1,7 @@
#include "Mutex.h"
#include <framework/serviceinterface/ServiceInterfaceStream.h>
const uint32_t MutexIF::BLOCKING = RTEMS_NO_TIMEOUT;
const uint32_t MutexIF::BLOCKING = RTEMS_WAIT;
gaisser commented 2020-06-08 19:37:23 +02:00
Outdated
Review
Copy Link

Looked through the RTEMS interface and unfortunately this is not correct.
RTEMS_NO_TIMEOUT is only the variable used for the TIMEOUT itself.
The RTEMS rtems_semaphore_obtain uses two different parameters:

  • The second parameter can be "RTEMS_WAIT" or "RTEMS_NO_WAIT".
  • The third parameter is the timeout. This can be RTEMS_NO_TIMEOUT. If the second parameter is on RTEMS_NO_WAIT, this parameter is ignored.

Our implementation of lockMutex takes a Timeout. If set to zero this could mean "Lock forever" or "Poll". If we check the value against "MutexIF::POLLING" and "MutexIF::BLOCKING" it is still not clear how long the mutex should be BLOCKING.

Looked through the RTEMS interface and unfortunately this is not correct. RTEMS_NO_TIMEOUT is only the variable used for the TIMEOUT itself. The RTEMS rtems_semaphore_obtain uses two different parameters: * The second parameter can be "RTEMS_WAIT" or "RTEMS_NO_WAIT". * The third parameter is the timeout. This can be RTEMS_NO_TIMEOUT. If the second parameter is on RTEMS_NO_WAIT, this parameter is ignored. Our implementation of lockMutex takes a Timeout. If set to zero this could mean "Lock forever" or "Poll". If we check the value against "MutexIF::POLLING" and "MutexIF::BLOCKING" it is still not clear how long the mutex should be BLOCKING.
muellerr commented 2020-06-09 13:27:42 +02:00
Outdated
Review
Copy Link

I changed it again. But I don't know what rtems_interval is (is it milliseconds)?
I also don't know what the numerical values of those RTEMS constants are so maybe
the implementatio ndoes not work like that.

I changed it again. But I don't know what rtems_interval is (is it milliseconds)? I also don't know what the numerical values of those RTEMS constants are so maybe the implementatio ndoes not work like that.
gaisser commented 2020-06-23 20:41:36 +02:00
Outdated
Review
Copy Link

Hm WAIT is 0 and NO_WAIT is 1. So you can not request a 1 ms wait.

Hm WAIT is 0 and NO_WAIT is 1. So you can not request a 1 ms wait.
const uint32_t MutexIF::POLLING = RTEMS_NO_WAIT;
uint8_t Mutex::count = 0;
@ -26,7 +26,20 @@ Mutex::~Mutex() {
}
ReturnValue_t Mutex::lockMutex(uint32_t timeoutMs) {
rtems_status_code status = rtems_semaphore_obtain(mutexId, RTEMS_WAIT, timeoutMs);
if(timeoutMs == MutexIF::BLOCKING) {
rtems_status_code status = rtems_semaphore_obtain(mutexId,
RTEMS_WAIT, timeoutMs);
}
else if(timeoutMs == MutexIF::POLLING) {
timeoutMs = RTEMS_NO_TIMEOUT;
rtems_status_code status = rtems_semaphore_obtain(mutexId,
RTEMS_NO_WAIT, timeoutMs);
}
else {
rtems_status_code status = rtems_semaphore_obtain(mutexId,
RTEMS_NO_WAIT, timeoutMs);
}
switch(status){
case RTEMS_SUCCESSFUL:
//semaphore obtained successfully

2
osal/rtems/Mutex.h
View File

@ -8,7 +8,7 @@ class Mutex : public MutexIF {
public:
Mutex();
~Mutex();
ReturnValue_t lockMutex(uint32_t timeoutMs);
ReturnValue_t lockMutex(uint32_t timeoutMs = MutexIF::BLOCKING);
ReturnValue_t unlockMutex();
private:
rtems_id mutexId;