On Fri, Jun 17, 2016 at 6:51 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
> ---
> cpukit/posix/include/rtems/posix/priorityimpl.h | 82
> ++++++++++---------------
> cpukit/posix/src/mutexgetprioceiling.c | 1 +
> cpukit/posix/src/mutexinit.c | 5 +-
> cpukit/posix/src/mutexsetprioceiling.c | 35 +++++++----
> cpukit/posix/src/psxpriorityisvalid.c | 8 +--
> cpukit/posix/src/pthread.c | 4 +-
> cpukit/posix/src/pthreadcreate.c | 11 ++--
> cpukit/posix/src/pthreadgetschedparam.c | 11 +++-
> cpukit/posix/src/pthreadsetschedparam.c | 11 ++--
> cpukit/posix/src/pthreadsetschedprio.c | 7 ++-
> 10 files changed, 94 insertions(+), 81 deletions(-)
>
> diff --git a/cpukit/posix/include/rtems/posix/priorityimpl.h
> b/cpukit/posix/include/rtems/posix/priorityimpl.h
> index e3f23e7..7e770f7 100644
> --- a/cpukit/posix/include/rtems/posix/priorityimpl.h
> +++ b/cpukit/posix/include/rtems/posix/priorityimpl.h
> @@ -30,29 +30,10 @@ extern "C" {
> *
> * @ingroup POSIXAPI
> *
> - * @brief Interface to the POSIX Priority Implementation
> - *
> - */
> -/**@{**/
> -
> -/**
> - * 1003.1b-1993,2.2.2.80 definition of priority, p. 19
> - *
> - * "Numerically higher values represent higher priorities."
> - *
> - * Thus, RTEMS Core has priorities run in the opposite sense of the POSIX
> API.
> - *
> - * There are only 254 posix priority levels since a task at priority level
> - * 255 would never run because of the RTEMS idle task. This is necessary
> - * because GNAT maps the lowest Ada task priority to the lowest thread
> - * priority. The lowest priority Ada task should get to run, so there is
> - * a fundamental conflict with having 255 priorities.
> + * @brief Interface to the POSIX Priority Implementation.
> *
> - * But since RTEMS can be configured with fewer than 256 priorities,
> - * we use the internal constant.
> + * @{
> */
> -#define POSIX_SCHEDULER_MAXIMUM_PRIORITY (PRIORITY_MAXIMUM - 1)
> -
>
> /**
> * This is the numerically least important POSIX priority.
> @@ -72,53 +53,58 @@ int _POSIX_Priority_Get_maximum( const Scheduler_Control
> *scheduler );
> /**
> * @brief Check if POSIX priority is valid.
> *
> - * 1003.1b-1993,2.2.2.80 definition of priority, p. 19
> - *
> - * "Numerically higher values represent higher priorities."
> - *
> - * Thus, RTEMS Core has priorities run in the opposite sense of the POSIX
> API.
> - *
> - * @param[in] priority is the priority to test
> - *
> - * @retval TRUE The priority is valid.
> - * @retval FALSE The priority is invalid.
> + * According to POSIX, numerically higher values represent higher priorities.
> + * Thus, SuperCore has priorities run in the opposite sense of the POSIX API.
> + *
> + * Let N be the maximum priority of this scheduler instance. The SuperCore
> + * priority zero is system reserved (PRIORITY_PSEUDO_ISR). There are only
> + * N - 1 POSIX API priority levels since a thread at SuperCore priority N
> would
> + * never run because of the idle threads. This is necessary because GNAT
> maps
> + * the lowest Ada task priority to the lowest thread priority. The lowest
> + * priority Ada task should get to run, so there is a fundamental conflict
> with
> + * having N priorities.
> + *
> + * @param[in] scheduler The scheduler instance.
> + * @param[in] priority The POSIX API priority to test.
> + *
> + * @retval true The priority is valid.
> + * @retval false Otherwise.
> */
> bool _POSIX_Priority_Is_valid(
> - int priority
> + const Scheduler_Control *scheduler,
> + int priority
> );
>
> /**
> - * @brief Convert POSIX priority to SuperCore priority.
> - *
> - * This method converts a POSIX API priority into onto the corresponding
> - * SuperCore value.
> + * @brief Converts POSIX priority to SuperCore priority.
> *
> - * @param[in] priority is the POSIX API priority.
> + * @param[in] scheduler The scheduler instance.
> + * @param[in] priority The POSIX API priority.
> *
> - * @return This method returns the corresponding SuperCore priority.
> + * @return Returns the corresponding SuperCore priority.
> */
> RTEMS_INLINE_ROUTINE Priority_Control _POSIX_Priority_To_core(
> - int priority
> + const Scheduler_Control *scheduler,
> + int priority
> )
> {
> - return (Priority_Control) (POSIX_SCHEDULER_MAXIMUM_PRIORITY - priority +
> 1);
> + return scheduler->maximum_priority - (Priority_Control) priority;
> }
>
> /**
> - * @brief Convert SuperCore priority To POSIX priority.
> - *
> - * This method converts a SuperCore priority into onto the corresponding
> - * POSIX API value.
> + * @brief Converts SuperCore priority to POSIX priority.
> *
> - * @param[in] priority is the POSIX API priority.
> + * @param[in] scheduler The scheduler instance.
> + * @param[in] priority The SuperCore priority.
> *
> - * @return This method returns the corresponding POSIX priority.
> + * @return Returns the corresponding POSIX API priority.
> */
> RTEMS_INLINE_ROUTINE int _POSIX_Priority_From_core(
> - Priority_Control priority
> + const Scheduler_Control *scheduler,
> + Priority_Control priority
> )
> {
> - return (POSIX_SCHEDULER_MAXIMUM_PRIORITY - priority + 1);
> + return (int) ( scheduler->maximum_priority - priority );
> }
>
> /** @} */
> diff --git a/cpukit/posix/src/mutexgetprioceiling.c
> b/cpukit/posix/src/mutexgetprioceiling.c
> index 2df4776..eda02cb 100644
> --- a/cpukit/posix/src/mutexgetprioceiling.c
> +++ b/cpukit/posix/src/mutexgetprioceiling.c
> @@ -46,6 +46,7 @@ int pthread_mutex_getprioceiling(
> _POSIX_Mutex_Acquire_critical( the_mutex, &queue_context );
>
> *prioceiling = _POSIX_Priority_From_core(
> + &_Scheduler_Table[ 0 ],
Why not _Scheduler_Get_own(executing)? Does it matter which scheduler
control is used.
> @@ -56,13 +52,26 @@ int pthread_mutex_setprioceiling(
> the_mutex = _POSIX_Mutex_Get_no_protection( mutex );
> _Assert( the_mutex != NULL );
>
> + scheduler = &_Scheduler_Table[ 0 ];
> +
ditto.
-Gedare
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
