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 +147 -84
muellerr commented 2020-05-29 14:05:45 +02:00
Owner
Copy Link

Fixes #91

implemented returning the right returnvalues,
some form corrections and general improvements.

I am not sure whether a default timeout value which blocks permanently is a good idea..

Fixes #91 implemented returning the right returnvalues, some form corrections and general improvements. I am not sure whether a default timeout value which blocks permanently is a good idea..
muellerr added the
feature
 label 2020-05-29 14:17:07 +02:00
muellerr changed title from FreeRTOS Mutex improvements to Mutex improvements 2020-06-04 20:27:10 +02:00
muellerr commented 2020-06-04 20:28:23 +02:00
Author
Owner
Copy Link

MutexIF improvements:

  1. TImeout values have new names: BLOCKING for blocking call (indefinite blocking!)
    and POLLING for polling call which returns immediately
  2. Polling call for Linux mutex implemented
MutexIF improvements: 1. TImeout values have new names: BLOCKING for blocking call (indefinite blocking!) and POLLING for polling call which returns immediately 2. Polling call for Linux mutex implemented
gaisser commented 2020-06-08 12:16:06 +02:00
Owner
Copy Link

RTEMS is untouched?

RTEMS is untouched?
gaisser self-assigned this 2020-06-08 12:16:11 +02:00
muellerr commented 2020-06-08 12:20:37 +02:00
Author
Owner
Copy Link

I have not set up a RTEMS development environment yet, maybe I should, I heard they have a simulator.. I can make the changes, but I can't test them for RTEMS. However, the itnernal unit tests can be used if RTEMS is set up to check whether everything works immediately.

I have not set up a RTEMS development environment yet, maybe I should, I heard they have a simulator.. I can make the changes, but I can't test them for RTEMS. However, the itnernal unit tests can be used if RTEMS is set up to check whether everything works immediately.
muellerr commented 2020-06-08 14:15:02 +02:00
Author
Owner
Copy Link

rtems POLLING and BLOCKING values. I hope those are correct. I did not implement it though.

rtems POLLING and BLOCKING values. I hope those are correct. I did not implement it though.
gaisser reviewed 2020-06-08 19:37:23 +02:00
osal/rtems/Mutex.cpp Outdated
@ -2,3 +2,3 @@
#include <framework/serviceinterface/ServiceInterfaceStream.h>
const uint32_t MutexIF::NO_TIMEOUT = RTEMS_NO_TIMEOUT;
const uint32_t MutexIF::BLOCKING = RTEMS_NO_TIMEOUT;
gaisser commented 2020-06-08 19:37:23 +02:00
Owner
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
Author
Owner
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
Owner
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.
muellerr commented 2020-07-13 22:45:20 +02:00
Author
Owner
Copy Link

I have an idea for RTEMS. How about encoding POLLING as zero (RTEMS_NO_WAIT) , BLOCKING as 0xffffffff (RTEMS_WAIT with RTEMS_NO_TIMEOUT) and anything between 0 and 0xffffffff is wating with the timeout?
and anything in between is waiting with the timeout, with the value being the timeout?

I have an idea for RTEMS. How about encoding POLLING as zero (RTEMS_NO_WAIT) , BLOCKING as 0xffffffff (RTEMS_WAIT with RTEMS_NO_TIMEOUT) and anything between 0 and 0xffffffff is wating with the timeout? and anything in between is waiting with the timeout, with the value being the timeout?
muellerr commented 2020-08-11 15:54:47 +02:00
Author
Owner
Copy Link

Pull request has been adapted, MutexIF has slightly different API now and takes type
of timeout as a parameter.

Pull request has been adapted, MutexIF has slightly different API now and takes type of timeout as a parameter.
gaisser closed this pull request 2020-08-25 12:13:30 +02:00
gaisser deleted branch mueller_MutexImprovements 2020-08-25 12:13:35 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
API Change

Changes the API, so Users need to adapted

  
Breaking API Change

Changes the API in a non backwards compatible way

  
bug

Something is not working

  
build

Issues related to the buildsystem, including CI

  
cosmetics

Small change most users won't notice

  
Documentation

Improvement of code documentation

  
duplicate

This issue or pull request already exists

  
feature

New feature

  
help wanted

Need some help

  
hotfix

Quick or important fix that is merged directly into master, causing a new revision

  
invalid

#worksforme

  
question

More information is needed

  
Refactor

Contains a refactoring of some code

  
Tests

Issues related to testing code

  
wontfix

This won't be fixed

No Label
API Change
Breaking API Change
bug
build
cosmetics
Documentation
duplicate
feature
help wanted
hotfix
invalid
question
Refactor
Tests
wontfix
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
gaisser
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#90
No description provided.
Delete Branch "KSat/fsfw:mueller_MutexImprovements"

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?