no figure in the file system design guide document
Hi, all I was reading 'RTEMS file system design guide' document and found there are many figures missing. (for example figure 3 and many.) I see "figure of ... goes here " texts in places for the figures. I tried generating the document from the source under doc directory, but it's the same and I checked https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/html/ but no figures. Under $RTEMS_ROOT/doc/filesystem, there is no .jpg or .png files. Can I get the document with figures? Without figures, it's not easy to understand. Or if it is a bug in the documentation, the writer of the document please fix it. Thanks! Regards, Chan Kim ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Documentation
---
cpukit/score/include/rtems/score/interr.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/cpukit/score/include/rtems/score/interr.h
b/cpukit/score/include/rtems/score/interr.h
index 2100c13..e0cedaf 100644
--- a/cpukit/score/include/rtems/score/interr.h
+++ b/cpukit/score/include/rtems/score/interr.h
@@ -43,8 +43,21 @@ extern "C" {
* can be reported.
*/
typedef enum {
+ /**
+ * @brief Errors of the core system.
+ *
+ * @see Internal_errors_Core_list.
+ */
INTERNAL_ERROR_CORE,
+
+ /**
+ * @brief Errors of the RTEMS API.
+ */
INTERNAL_ERROR_RTEMS_API,
+
+ /**
+ * @brief Errors of the POSIX API.
+ */
INTERNAL_ERROR_POSIX_API,
/**
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] tests: Refactor parallel test execution
---
cpukit/sapi/Makefile.am| 1 +
cpukit/sapi/include/rtems/test.h | 109 ++
cpukit/sapi/src/testparallel.c | 151 +++
testsuites/smptests/smpatomic01/init.c | 264 ++---
4 files changed, 375 insertions(+), 150 deletions(-)
create mode 100644 cpukit/sapi/src/testparallel.c
diff --git a/cpukit/sapi/Makefile.am b/cpukit/sapi/Makefile.am
index a7eaad5..b58b3a2 100644
--- a/cpukit/sapi/Makefile.am
+++ b/cpukit/sapi/Makefile.am
@@ -42,6 +42,7 @@ libsapi_a_SOURCES += src/profilingiterate.c
libsapi_a_SOURCES += src/profilingreportxml.c
libsapi_a_SOURCES += src/testbeginend.c
libsapi_a_SOURCES += src/testextension.c
+libsapi_a_SOURCES += src/testparallel.c
libsapi_a_CPPFLAGS = $(AM_CPPFLAGS)
include $(srcdir)/preinstall.am
diff --git a/cpukit/sapi/include/rtems/test.h b/cpukit/sapi/include/rtems/test.h
index 48a33a0..096b9ad 100644
--- a/cpukit/sapi/include/rtems/test.h
+++ b/cpukit/sapi/include/rtems/test.h
@@ -17,6 +17,8 @@
#include
#include
+#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -116,6 +118,113 @@ static inline int rtems_test_endk(void)
return rtems_test_end_with_plugin(printk_plugin, NULL);
}
+/**
+ * @brief Internal context for parallel job execution.
+ */
+typedef struct {
+ Atomic_Ulong stop;
+ SMP_barrier_Control barrier;
+ size_t worker_count;
+ rtems_id stop_worker_timer_id;
+ rtems_id master_id;
+} rtems_test_parallel_context;
+
+/**
+ * @brief Basic parallel job description.
+ */
+typedef struct {
+ /**
+ * @brief Initialization handler.
+ *
+ * This handler executes only in the context of the master worker before the
+ * job body handler.
+ *
+ * @param[in] ctx The parallel context.
+ * @param[in] arg The user specified argument.
+ */
+ void (*init)(
+rtems_test_parallel_context *ctx,
+void *arg
+ );
+
+ /**
+ * @brief Job body handler.
+ *
+ * @param[in] ctx The parallel context.
+ * @param[in] arg The user specified argument.
+ * @param[in] worker_index The worker index. It ranges from 0 to the
+ * processor count minus one.
+ */
+ void (*body)(
+rtems_test_parallel_context *ctx,
+void *arg,
+size_t worker_index
+ );
+
+ /**
+ * @brief Finalization handler.
+ *
+ * This handler executes only in the context of the master worker after the
+ * job body handler.
+ *
+ * @param[in] ctx The parallel context.
+ * @param[in] arg The user specified argument.
+ */
+ void (*fini)(
+rtems_test_parallel_context *ctx,
+void *arg
+ );
+
+ void *arg;
+} rtems_test_parallel_job;
+
+/**
+ * @brief Indicates if a job body should stop its work loop.
+ *
+ * @param[in] ctx The parallel context.
+ *
+ * @retval true The job body should stop its work loop and return to the
caller.
+ * @retval false Otherwise.
+ */
+static inline bool rtems_test_parallel_stop_job(
+ rtems_test_parallel_context *ctx
+)
+{
+ return _Atomic_Load_ulong(&ctx->stop, ATOMIC_ORDER_RELAXED) != 0;
+}
+
+/**
+ * @brief Indicates if a worker is the master worker.
+ *
+ * The master worker is the thread that called rtems_test_parallel().
+ *
+ * @param[in] worker_index The worker index.
+ *
+ * @retval true This is the master worker.
+ * @retval false Otherwise.
+ */
+static inline bool rtems_test_parallel_is_master_worker(size_t worker_index)
+{
+ return worker_index == 0;
+}
+
+/**
+ * @brief Runs a bunch of jobs in parallel on all processors of the system.
+ *
+ * There are SMP barriers before and after the job body.
+ *
+ * @param[in] ctx The parallel context
+ * @param[in] non_master_worker_priority Indicates the priority of the worker
+ * @param[in] jobs Indicates the pointer to the first job to be executed
+ * @param[in] job_count Indicates the total number of jobs to be executed
+ */
+void rtems_test_parallel(
+ rtems_test_parallel_context *ctx,
+ rtems_task_priority non_master_worker_priority,
+ const rtems_test_parallel_job *jobs,
+ size_t job_count
+);
+
/** @} */
#ifdef __cplusplus
diff --git a/cpukit/sapi/src/testparallel.c b/cpukit/sapi/src/testparallel.c
new file mode 100644
index 000..e47ebbd
--- /dev/null
+++ b/cpukit/sapi/src/testparallel.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 2013-2015 embedded brains GmbH. All rights reserved.
+ *
+ * embedded brains GmbH
+ * Dornierstr. 4
+ * 82178 Puchheim
+ * Germany
+ *
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+
+#ifdef HAVE_CONFIG_H
+ #include "config.h"
+#endif
+
+#include
+#include
+#include
+
+static void stop_worker_timer(rtems_id timer_id, void *arg)
+{
+ rtems_test_parallel_context *ctx = arg;
+
+ _Atomic_Store_ulong(&ctx->stop, 1, ATOMIC_ORDER_RELAXED);
+}
+
+static void start_worker_stop_timer(rtems_test_parallel_context *ctx)
+{
+ rtems_status_code sc;
+
+ _Atomic_Store_ulong(&ctx->stop, 0, ATOMIC_ORDER_RE
Re: [PATCH] score: Documentation
OK to apply if it looks correct in generated doxygen. (Some
instructions are buried in https://devel.rtems.org/wiki/GCI/Projects
look for do_doxygen)
Gedare
On Wed, Mar 4, 2015 at 7:07 AM, Alexander Krutwig
wrote:
> ---
> cpukit/score/include/rtems/score/interr.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/cpukit/score/include/rtems/score/interr.h
> b/cpukit/score/include/rtems/score/interr.h
> index 2100c13..e0cedaf 100644
> --- a/cpukit/score/include/rtems/score/interr.h
> +++ b/cpukit/score/include/rtems/score/interr.h
> @@ -43,8 +43,21 @@ extern "C" {
> * can be reported.
> */
> typedef enum {
> + /**
> + * @brief Errors of the core system.
> + *
> + * @see Internal_errors_Core_list.
> + */
>INTERNAL_ERROR_CORE,
> +
> + /**
> + * @brief Errors of the RTEMS API.
> + */
>INTERNAL_ERROR_RTEMS_API,
> +
> + /**
> + * @brief Errors of the POSIX API.
> + */
>INTERNAL_ERROR_POSIX_API,
>
>/**
> --
> 1.8.4.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] tests: Refactor parallel test execution
It seems that these changes to test.h and the new testparallel.c
belong in the testsuites/smptests area, perhaps in a shared/
subdirectory. Certainly I don't see why testparallel.c is in sapi. (I
don't recall why we have testing framework in the sapi though...)
On Wed, Mar 4, 2015 at 7:33 AM, Alexander Krutwig
wrote:
> ---
> cpukit/sapi/Makefile.am| 1 +
> cpukit/sapi/include/rtems/test.h | 109 ++
> cpukit/sapi/src/testparallel.c | 151 +++
> testsuites/smptests/smpatomic01/init.c | 264
> ++---
> 4 files changed, 375 insertions(+), 150 deletions(-)
> create mode 100644 cpukit/sapi/src/testparallel.c
>
> diff --git a/cpukit/sapi/Makefile.am b/cpukit/sapi/Makefile.am
> index a7eaad5..b58b3a2 100644
> --- a/cpukit/sapi/Makefile.am
> +++ b/cpukit/sapi/Makefile.am
> @@ -42,6 +42,7 @@ libsapi_a_SOURCES += src/profilingiterate.c
> libsapi_a_SOURCES += src/profilingreportxml.c
> libsapi_a_SOURCES += src/testbeginend.c
> libsapi_a_SOURCES += src/testextension.c
> +libsapi_a_SOURCES += src/testparallel.c
> libsapi_a_CPPFLAGS = $(AM_CPPFLAGS)
>
> include $(srcdir)/preinstall.am
> diff --git a/cpukit/sapi/include/rtems/test.h
> b/cpukit/sapi/include/rtems/test.h
> index 48a33a0..096b9ad 100644
> --- a/cpukit/sapi/include/rtems/test.h
> +++ b/cpukit/sapi/include/rtems/test.h
> @@ -17,6 +17,8 @@
>
> #include
> #include
> +#include
> +#include
>
> #ifdef __cplusplus
> extern "C" {
> @@ -116,6 +118,113 @@ static inline int rtems_test_endk(void)
>return rtems_test_end_with_plugin(printk_plugin, NULL);
> }
>
> +/**
> + * @brief Internal context for parallel job execution.
> + */
> +typedef struct {
> + Atomic_Ulong stop;
> + SMP_barrier_Control barrier;
> + size_t worker_count;
I'd prefer to only see size_t to represent sizes e.g. in bytes. For
this field you can probably use uint8_t anyway? Same goes for all the
rest of the size_t here. It was size_t before, but that wasn't in a
public-facing header..
Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] tests: Refactor parallel test execution
On 04/03/15 15:17, Gedare Bloom wrote: It seems that these changes to test.h and the new testparallel.c belong in the testsuites/smptests area, perhaps in a shared/ subdirectory. Certainly I don't see why testparallel.c is in sapi. (I don't recall why we have testing framework in the sapi though...) The problem with this shared subdirectory in the testsuite area is that this leads to copy and paste in the Makefiles and this is a maintenance nightmare. We probably need a library for all tests. This is a build system issue, which I would like to postpone after the waf integration. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/8] score: Simplify and fix signal delivery
Deliver the POSIX signals after the thread state was updated to avoid
race-conditions on SMP configurations.
Update #2273.
---
cpukit/posix/src/psignalunblockthread.c | 22 +++
cpukit/rtems/src/signalsend.c | 1 -
cpukit/score/include/rtems/score/threadimpl.h | 54 ++-
cpukit/score/src/threadrestart.c | 1 -
4 files changed, 26 insertions(+), 52 deletions(-)
diff --git a/cpukit/posix/src/psignalunblockthread.c
b/cpukit/posix/src/psignalunblockthread.c
index c93dcfc..c56c150 100644
--- a/cpukit/posix/src/psignalunblockthread.c
+++ b/cpukit/posix/src/psignalunblockthread.c
@@ -35,6 +35,17 @@
#include
#include
+static bool _POSIX_signals_Unblock_thread_done(
+ Thread_Control*the_thread,
+ POSIX_API_Control *api,
+ bool status
+)
+{
+ _Thread_Add_post_switch_action( the_thread, &api->Signal_action );
+
+ return status;
+}
+
bool _POSIX_signals_Unblock_thread(
Thread_Control *the_thread,
int signo,
@@ -47,8 +58,6 @@ bool _POSIX_signals_Unblock_thread(
api = the_thread->API_Extensions[ THREAD_API_POSIX ];
- _Thread_Add_post_switch_action( the_thread, &api->Signal_action );
-
mask = signo_to_mask( signo );
/*
@@ -71,14 +80,14 @@ bool _POSIX_signals_Unblock_thread(
}
_Thread_queue_Extract_with_proxy( the_thread );
- return true;
+ return _POSIX_signals_Unblock_thread_done( the_thread, api, true );
}
/*
* This should only be reached via pthread_kill().
*/
-return false;
+return _POSIX_signals_Unblock_thread_done( the_thread, api, false );
}
/*
@@ -111,10 +120,7 @@ bool _POSIX_signals_Unblock_thread(
(void) _Watchdog_Remove( &the_thread->Timer );
_Thread_Unblock( the_thread );
}
-
-} else if ( the_thread->current_state == STATES_READY ) {
- _Thread_Signal_notification( the_thread );
}
}
- return false;
+ return _POSIX_signals_Unblock_thread_done( the_thread, api, false );
}
diff --git a/cpukit/rtems/src/signalsend.c b/cpukit/rtems/src/signalsend.c
index cb989c4..c86c399 100644
--- a/cpukit/rtems/src/signalsend.c
+++ b/cpukit/rtems/src/signalsend.c
@@ -51,7 +51,6 @@ rtems_status_code rtems_signal_send(
the_thread,
&api->Signal_action
);
- _Thread_Signal_notification( the_thread );
} else {
_ASR_Post_signals( asr, signal_set, &asr->signals_pending );
}
diff --git a/cpukit/score/include/rtems/score/threadimpl.h
b/cpukit/score/include/rtems/score/threadimpl.h
index 07c5b2f..e5e51ec 100644
--- a/cpukit/score/include/rtems/score/threadimpl.h
+++ b/cpukit/score/include/rtems/score/threadimpl.h
@@ -695,45 +695,6 @@ RTEMS_INLINE_ROUTINE Thread_Control
*_Thread_Internal_allocate( void )
_Objects_Allocate_unprotected( &_Thread_Internal_information );
}
-RTEMS_INLINE_ROUTINE void _Thread_Request_dispatch_if_executing(
- Thread_Control *thread
-)
-{
-#if defined(RTEMS_SMP)
- if ( _Thread_Is_executing_on_a_processor( thread ) ) {
-const Per_CPU_Control *cpu_of_executing = _Per_CPU_Get();
-Per_CPU_Control *cpu_of_thread = _Thread_Get_CPU( thread );
-
-cpu_of_thread->dispatch_necessary = true;
-
-if ( cpu_of_executing != cpu_of_thread ) {
- _Per_CPU_Send_interrupt( cpu_of_thread );
-}
- }
-#else
- (void) thread;
-#endif
-}
-
-RTEMS_INLINE_ROUTINE void _Thread_Signal_notification( Thread_Control *thread )
-{
- if ( _ISR_Is_in_progress() && _Thread_Is_executing( thread ) ) {
-_Thread_Dispatch_necessary = true;
- } else {
-#if defined(RTEMS_SMP)
-if ( _Thread_Is_executing_on_a_processor( thread ) ) {
- const Per_CPU_Control *cpu_of_executing = _Per_CPU_Get();
- Per_CPU_Control *cpu_of_thread = _Thread_Get_CPU( thread );
-
- if ( cpu_of_executing != cpu_of_thread ) {
-cpu_of_thread->dispatch_necessary = true;
-_Per_CPU_Send_interrupt( cpu_of_thread );
- }
-}
-#endif
- }
-}
-
/**
* @brief Gets the heir of the processor and makes it executing.
*
@@ -870,15 +831,24 @@ RTEMS_INLINE_ROUTINE void _Thread_Add_post_switch_action(
Thread_Action *action
)
{
- Per_CPU_Control *cpu;
+ Per_CPU_Control *cpu_of_thread;
ISR_Levellevel;
- cpu = _Thread_Action_ISR_disable_and_acquire( thread, &level );
+ cpu_of_thread = _Thread_Action_ISR_disable_and_acquire( thread, &level );
+ cpu_of_thread->dispatch_necessary = true;
+
+#if defined(RTEMS_SMP)
+ if ( _Per_CPU_Get() != cpu_of_thread ) {
+_Per_CPU_Send_interrupt( cpu_of_thread );
+ }
+#endif
+
_Chain_Append_if_is_off_chain_unprotected(
&thread->Post_switch_actions.Chain,
&action->Node
);
- _Thread_Action_release_and_ISR_enable( cpu, level );
+
+ _Thread_Action_release_and_ISR_enable( cpu_of_thread, level );
}
RTEMS_INLINE_ROUTINE bool _Thread_Is_life_restarting(
diff --git a/cpukit/score/src/threadrestart.c b/cpukit/score/src/thread
[PATCH 1/8] score: Update _Thread_Heir only if necessary
Previously, the _Thread_Heir was updated unconditionally in case a new
heir was determined. The _Thread_Dispatch_necessary was only updated in
case the executing thread was preemptible or an internal thread was
unblocked. Change this to update the _Thread_Heir and
_Thread_Dispatch_necessary only in case the currently selected heir
thread is preemptible or a dispatch is forced. Move the schedule
decision into the change priority operation and use the schedule
operation only in rtems_task_mode() in case preemption is enabled or an
ASR dispatch is necessary. This is a behaviour change. Previously, the
RTEMS_NO_PREEMPT also prevented signal delivery in certain cases (not
always). Now, signal delivery is no longer influenced by
RTEMS_NO_PREEMPT. Since the currently selected heir thread is used to
determine if a new heir is chosen, non-preemptible heir threads
currently not executing now prevent a new heir. This may have an
application impact, see change test tm04. Document this change in sp04.
Update #2273.
---
cpukit/rtems/src/taskmode.c| 50 ---
cpukit/score/include/rtems/score/schedulerimpl.h | 15 ++--
cpukit/score/src/schedulercbsunblock.c | 8 +-
cpukit/score/src/scheduleredfchangepriority.c | 2 +
cpukit/score/src/scheduleredfunblock.c | 8 +-
cpukit/score/src/schedulerprioritychangepriority.c | 2 +
cpukit/score/src/schedulerpriorityunblock.c| 8 +-
cpukit/score/src/schedulerpriorityyield.c | 12 +--
cpukit/score/src/schedulersimplechangepriority.c | 2 +
cpukit/score/src/schedulersimpleunblock.c | 8 +-
cpukit/score/src/threadchangepriority.c| 9 +-
testsuites/sptests/sp04/system.h | 1 +
testsuites/sptests/sp04/task1.c| 99 ++
testsuites/tmtests/tm04/task1.c| 3 +
14 files changed, 152 insertions(+), 75 deletions(-)
diff --git a/cpukit/rtems/src/taskmode.c b/cpukit/rtems/src/taskmode.c
index eeb3e0f..1056c6b 100644
--- a/cpukit/rtems/src/taskmode.c
+++ b/cpukit/rtems/src/taskmode.c
@@ -21,42 +21,10 @@
#include
#include
#include
+#include
#include
#include
-static void _RTEMS_Tasks_Dispatch_if_necessary(
- Thread_Control *executing,
- boolneeds_asr_dispatching
-)
-{
- if ( _Thread_Dispatch_is_enabled() ) {
-bool dispatch_necessary = needs_asr_dispatching;
-
-/*
- * FIXME: This locking approach is brittle. It only works since the
- * current simple SMP scheduler has no support for the non-preempt mode.
- */
-#if defined( RTEMS_SMP )
-ISR_Level level;
-
-_ISR_Disable_without_giant( level );
-#endif
-
-if ( !_Thread_Is_heir( executing ) && executing->is_preemptible ) {
- dispatch_necessary = true;
- _Thread_Dispatch_necessary = dispatch_necessary;
-}
-
-#if defined( RTEMS_SMP )
-_ISR_Enable_without_giant( level );
-#endif
-
-if ( dispatch_necessary ) {
- _Thread_Dispatch();
-}
- }
-}
-
rtems_status_code rtems_task_mode(
rtems_mode mode_set,
rtems_mode mask,
@@ -66,6 +34,7 @@ rtems_status_code rtems_task_mode(
Thread_Control *executing;
RTEMS_API_Control *api;
ASR_Information*asr;
+ boolpreempt_enabled;
boolneeds_asr_dispatching;
rtems_mode old_mode;
@@ -91,6 +60,7 @@ rtems_status_code rtems_task_mode(
/*
* These are generic thread scheduling characteristics.
*/
+ preempt_enabled = false;
if ( mask & RTEMS_PREEMPT_MASK ) {
#if defined( RTEMS_SMP )
if ( rtems_configuration_is_smp_enabled() &&
@@ -98,8 +68,10 @@ rtems_status_code rtems_task_mode(
return RTEMS_NOT_IMPLEMENTED;
}
#endif
+bool is_preempt_enabled = _Modes_Is_preempt( mode_set );
-executing->is_preemptible = _Modes_Is_preempt( mode_set );
+preempt_enabled = !executing->is_preemptible && is_preempt_enabled;
+executing->is_preemptible = is_preempt_enabled;
}
if ( mask & RTEMS_TIMESLICE_MASK ) {
@@ -137,7 +109,15 @@ rtems_status_code rtems_task_mode(
}
}
- _RTEMS_Tasks_Dispatch_if_necessary( executing, needs_asr_dispatching );
+ if ( preempt_enabled || needs_asr_dispatching ) {
+ISR_Level level;
+
+_Thread_Disable_dispatch();
+_ISR_Disable( level );
+_Scheduler_Schedule( executing );
+_ISR_Enable( level );
+_Thread_Enable_dispatch();
+ }
return RTEMS_SUCCESSFUL;
}
diff --git a/cpukit/score/include/rtems/score/schedulerimpl.h
b/cpukit/score/include/rtems/score/schedulerimpl.h
index 31ae6d1..7bf4038 100644
--- a/cpukit/score/include/rtems/score/schedulerimpl.h
+++ b/cpukit/score/include/rtems/score/schedulerimpl.h
@@ -314,6 +314,9 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Unblock(
Thread_Control *the_thread )
* must ensure that the priority value actually changed and is not equal to the
* current priority value.
*
+ * The operation must update the heir and thread dispatch neces
[PATCH 8/8] score: Implement fine-grained locking for events
Use the ISR lock of the thread object to protect the event state and
use the Giant lock only for the blocking operations.
Update #2273.
---
cpukit/rtems/Makefile.am | 1 -
cpukit/rtems/include/rtems/rtems/eventimpl.h | 49 +++---
cpukit/rtems/src/event.c | 3 -
cpukit/rtems/src/eventdata.c | 23 -
cpukit/rtems/src/eventreceive.c | 13 +--
cpukit/rtems/src/eventseize.c| 77 +++
cpukit/rtems/src/eventsend.c | 8 +-
cpukit/rtems/src/eventsurrender.c| 139 ---
cpukit/rtems/src/eventtimeout.c | 90 +
cpukit/rtems/src/systemeventreceive.c| 13 +--
cpukit/rtems/src/systemeventsend.c | 8 +-
cpukit/rtems/src/tasks.c | 2 -
testsuites/sptests/spintrcritical10/init.c | 64 ++--
testsuites/sptests/spintrcritical21/init.c | 14 ++-
testsuites/sptests/spsize/size.c | 2 -
15 files changed, 254 insertions(+), 252 deletions(-)
delete mode 100644 cpukit/rtems/src/eventdata.c
diff --git a/cpukit/rtems/Makefile.am b/cpukit/rtems/Makefile.am
index a1fafb1..5e6f2ea 100644
--- a/cpukit/rtems/Makefile.am
+++ b/cpukit/rtems/Makefile.am
@@ -211,7 +211,6 @@ librtems_a_SOURCES += src/eventseize.c
librtems_a_SOURCES += src/eventsend.c
librtems_a_SOURCES += src/eventsurrender.c
librtems_a_SOURCES += src/eventtimeout.c
-librtems_a_SOURCES += src/eventdata.c
librtems_a_SOURCES += src/systemeventsend.c
librtems_a_SOURCES += src/systemeventreceive.c
diff --git a/cpukit/rtems/include/rtems/rtems/eventimpl.h
b/cpukit/rtems/include/rtems/rtems/eventimpl.h
index 60b6b51..460b7ce 100644
--- a/cpukit/rtems/include/rtems/rtems/eventimpl.h
+++ b/cpukit/rtems/include/rtems/rtems/eventimpl.h
@@ -33,16 +33,6 @@ extern "C" {
*/
/**
- * This constant is defined to extern most of the time when using
- * this header file. However by defining it to nothing, the data
- * declared in this header file can be instantiated. This is done
- * in a single per manager file.
- */
-#ifndef RTEMS_EVENT_EXTERN
-#define RTEMS_EVENT_EXTERN extern
-#endif
-
-/**
* This constant is passed as the event_in to the
* rtems_event_receive directive to determine which events are pending.
*/
@@ -54,10 +44,6 @@ extern "C" {
*/
#define EVENT_SETS_NONE_PENDING 0
-RTEMS_EVENT_EXTERN Thread_blocking_operation_States _Event_Sync_state;
-
-RTEMS_EVENT_EXTERN Thread_blocking_operation_States _System_event_Sync_state;
-
/**
* @brief Event Manager Initialization
*
@@ -71,30 +57,23 @@ RTEMS_EVENT_EXTERN Thread_blocking_operation_States
_System_event_Sync_state;
void _Event_Manager_initialization( void );
void _Event_Seize(
- rtems_event_set event_in,
- rtems_option option_set,
- rtems_intervalticks,
- rtems_event_set *event_out,
- Thread_Control *executing,
- Event_Control*event,
- Thread_blocking_operation_States *sync_state,
- States_Controlwait_state
+ rtems_event_setevent_in,
+ rtems_option option_set,
+ rtems_interval ticks,
+ rtems_event_set *event_out,
+ Thread_Control*executing,
+ Event_Control *event,
+ Thread_Wait_flags wait_class,
+ States_Control block_state,
+ ISR_lock_Context *lock_context
);
-/**
- * @brief Surrender Event
- *
- * - INTERRUPT LATENCY:
- *+ before flash
- *+ after flash
- *+ check sync
- */
void _Event_Surrender(
- Thread_Control *the_thread,
- rtems_event_set event_in,
- Event_Control*event,
- Thread_blocking_operation_States *sync_state,
- States_Controlwait_state
+ Thread_Control*the_thread,
+ rtems_event_setevent_in,
+ Event_Control *event,
+ Thread_Wait_flags wait_class,
+ ISR_lock_Context *lock_context
);
/**
diff --git a/cpukit/rtems/src/event.c b/cpukit/rtems/src/event.c
index 3a1359e..7ec44d7 100644
--- a/cpukit/rtems/src/event.c
+++ b/cpukit/rtems/src/event.c
@@ -22,9 +22,6 @@
void _Event_Manager_initialization( void )
{
- _Event_Sync_state = THREAD_BLOCKING_OPERATION_SYNCHRONIZED;
- _System_event_Sync_state = THREAD_BLOCKING_OPERATION_SYNCHRONIZED;
-
/*
* Register the MP Process Packet routine.
*/
diff --git a/cpukit/rtems/src/eventdata.c b/cpukit/rtems/src/eventdata.c
deleted file mode 100644
index 93fa473..000
--- a/cpukit/rtems/src/eventdata.c
+++ /dev/null
@@ -1,23 +0,0 @@
-/**
- * @file
- *
- * @brief Instantiate RTEMS Event Data
- * @ingroup ClassicEvent
- */
-
-/*
- * COPYRIGHT (c) 1989-2007.
- * On-Line Applications Research Corporation (OAR).
- *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
[PATCH 5/8] score: Add ISR lock to Objects_Control
This enables per-object SMP locks on SMP configurations and is the first
step to support fine-grained locking. On uni-processor configuration
there will be no overhead. The _Objects_Acquire() is intended to
replace _Objects_Get_isr_disable().
Update #2273.
---
cpukit/score/Makefile.am | 1 +
cpukit/score/include/rtems/score/object.h | 3 +
cpukit/score/include/rtems/score/objectimpl.h | 80 +++
cpukit/score/src/objectacquire.c | 80 +++
cpukit/score/src/objectclose.c| 2 +
5 files changed, 166 insertions(+)
create mode 100644 cpukit/score/src/objectacquire.c
diff --git a/cpukit/score/Makefile.am b/cpukit/score/Makefile.am
index a2d440b..509a243 100644
--- a/cpukit/score/Makefile.am
+++ b/cpukit/score/Makefile.am
@@ -202,6 +202,7 @@ libscore_a_SOURCES += src/objectallocate.c
src/objectclose.c \
src/objectgetinfo.c src/objectgetinfoid.c src/objectapimaximumclass.c \
src/objectnamespaceremove.c \
src/objectactivecount.c
+libscore_a_SOURCES += src/objectacquire.c
## SCHEDULER_C_FILES
libscore_a_SOURCES += src/log2table.c
diff --git a/cpukit/score/include/rtems/score/object.h
b/cpukit/score/include/rtems/score/object.h
index 70e5fe6..d0cb579 100644
--- a/cpukit/score/include/rtems/score/object.h
+++ b/cpukit/score/include/rtems/score/object.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -236,6 +237,8 @@ typedef struct {
Objects_Id id;
/** This is the object's name. */
Objects_Name name;
+ /** This is the object's ISR lock. */
+ ISR_LOCK_DEFINE( Lock )
} Objects_Control;
#if defined( RTEMS_MULTIPROCESSING )
diff --git a/cpukit/score/include/rtems/score/objectimpl.h
b/cpukit/score/include/rtems/score/objectimpl.h
index 2928eff..c681c9a 100644
--- a/cpukit/score/include/rtems/score/objectimpl.h
+++ b/cpukit/score/include/rtems/score/objectimpl.h
@@ -591,6 +591,83 @@ Objects_Control *_Objects_Get_no_protection(
);
/**
+ * @brief Acquires an object by its identifier.
+ *
+ * This function is similar to _Objects_Get_isr_disable(). It acquires the
+ * object specific ISR lock for local objects. Thread dispatching is not
+ * disabled for local objects. For remote objects thread dispatching is
+ * disabled.
+ *
+ * @param[in] information The object information.
+ * @param[in] id The object identifier.
+ * @param[in] location The location of the object.
+ * @param[in] lock_context The lock context for local objects.
+ *
+ * @retval object The object corresponding to the identifier.
+ * @retval NULL No object exists in this domain for this identifer.
+ *
+ * @see _Objects_Release(), _Objects_Release_and_ISR_enable(), and
+ * _Objects_Release_and_thread_dispatch_disable().
+ */
+Objects_Control *_Objects_Acquire(
+ const Objects_Information *information,
+ Objects_Id id,
+ Objects_Locations *location,
+ ISR_lock_Context *lock_context
+);
+
+/**
+ * @brief Releases a local object.
+ *
+ * @param[in] the_object The local object acquired by _Objects_Acquire().
+ * @param[in] lock_context The lock context initialized by _Objects_Acquire().
+ */
+RTEMS_INLINE_ROUTINE void _Objects_Release(
+ Objects_Control *the_object,
+ ISR_lock_Context *lock_context
+)
+{
+ _ISR_lock_Release( &the_object->Lock, lock_context );
+}
+
+/**
+ * @brief Releases a local object and restores the interrupt level.
+ *
+ * @param[in] the_object The local object acquired by _Objects_Acquire().
+ * @param[in] lock_context The lock context initialized by _Objects_Acquire().
+ */
+RTEMS_INLINE_ROUTINE void _Objects_Release_and_ISR_enable(
+ Objects_Control *the_object,
+ ISR_lock_Context *lock_context
+)
+{
+ _ISR_lock_Release_and_ISR_enable( &the_object->Lock, lock_context );
+}
+
+/**
+ * @brief Releases a local object, disables thread dispatching and restores the
+ * interrupt level.
+ *
+ * @param[in] the_object The local object acquired by _Objects_Acquire().
+ * @param[in] lock_context The lock context initialized by _Objects_Acquire().
+ *
+ * @return The current processor.
+ */
+RTEMS_INLINE_ROUTINE Per_CPU_Control *
+_Objects_Release_and_thread_dispatch_disable(
+ Objects_Control *the_object,
+ ISR_lock_Context *lock_context
+)
+{
+ Per_CPU_Control *cpu_self = _Per_CPU_Get();
+
+ _Thread_Dispatch_disable_critical( cpu_self );
+ _Objects_Release_and_ISR_enable( the_object, lock_context );
+
+ return cpu_self;
+}
+
+/**
* Like @ref _Objects_Get, but is used to find "next" open object.
*
* @param[in] information points to an object class information block.
@@ -903,6 +980,7 @@ RTEMS_INLINE_ROUTINE void _Objects_Open(
_Assert( the_object != NULL );
the_object->name = name;
+ _ISR_lock_Initialize( &the_object->Lock, "Object" );
_Objects_Set_local_object(
information,
@@ -927,6 +1005,7 @@ RTEMS_INLINE_ROUTINE void _Objects_Open_u32(
{
/* ASSERT: information->i
[PATCH 4/8] score: Thread dispatch dis/enable without Giant
Update #2273.
---
cpukit/score/include/rtems/score/threaddispatch.h | 104 +-
1 file changed, 82 insertions(+), 22 deletions(-)
diff --git a/cpukit/score/include/rtems/score/threaddispatch.h
b/cpukit/score/include/rtems/score/threaddispatch.h
index 80de19d..037cf27 100644
--- a/cpukit/score/include/rtems/score/threaddispatch.h
+++ b/cpukit/score/include/rtems/score/threaddispatch.h
@@ -190,6 +190,16 @@ RTEMS_INLINE_ROUTINE void _Thread_Dispatch_initialization(
void )
return disable_level;
}
+
+ RTEMS_INLINE_ROUTINE void _Giant_Acquire( Per_CPU_Control *cpu_self )
+ {
+(void) cpu_self;
+ }
+
+ RTEMS_INLINE_ROUTINE void _Giant_Release( Per_CPU_Control *cpu_self )
+ {
+(void) cpu_self;
+ }
#endif /* RTEMS_SMP */
/**
@@ -227,31 +237,62 @@ void _Thread_Dispatch( void );
void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level );
/**
- * This routine prevents dispatching.
+ * @brief Disables thread dispatching inside a critical section (interrupts
+ * disabled).
+ *
+ * This function does not acquire the Giant lock.
+ *
+ * @param[in] cpu_self The current processor.
*/
-
-#if defined ( __THREAD_DO_NOT_INLINE_DISABLE_DISPATCH__ )
-void _Thread_Disable_dispatch( void );
-#else
-RTEMS_INLINE_ROUTINE void _Thread_Disable_dispatch( void )
+RTEMS_INLINE_ROUTINE void _Thread_Dispatch_disable_critical(
+ Per_CPU_Control *cpu_self
+)
{
- _Thread_Dispatch_increment_disable_level();
- RTEMS_COMPILER_MEMORY_BARRIER();
+ uint32_t disable_level = cpu_self->thread_dispatch_disable_level;
+
+ _Profiling_Thread_dispatch_disable( cpu_self, disable_level );
+ cpu_self->thread_dispatch_disable_level = disable_level + 1;
}
-#endif
-RTEMS_INLINE_ROUTINE void _Thread_Enable_dispatch_body( void )
+/**
+ * @brief Disables thread dispatching.
+ *
+ * This function does not acquire the Giant lock.
+ *
+ * @return The current processor.
+ */
+RTEMS_INLINE_ROUTINE Per_CPU_Control *_Thread_Dispatch_disable( void )
{
Per_CPU_Control *cpu_self;
- uint32_t disable_level;
+
+#if defined( RTEMS_SMP ) || defined( RTEMS_PROFILING )
+ ISR_Level level;
+
+ _ISR_Disable_without_giant( level );
+#endif
cpu_self = _Per_CPU_Get();
+ _Thread_Dispatch_disable_critical( cpu_self );
-#if defined( RTEMS_SMP )
- _Giant_Release( cpu_self );
+#if defined( RTEMS_SMP ) || defined( RTEMS_PROFILING )
+ _ISR_Enable_without_giant( level );
#endif
- disable_level = cpu_self->thread_dispatch_disable_level;
+ return cpu_self;
+}
+
+/**
+ * @brief Enables thread dispatching.
+ *
+ * May perfrom a thread dispatch if necessary as a side-effect.
+ *
+ * This function does not release the Giant lock.
+ *
+ * @param[in] cpu_self The current processor.
+ */
+RTEMS_INLINE_ROUTINE void _Thread_Dispatch_enable( Per_CPU_Control *cpu_self )
+{
+ uint32_t disable_level = cpu_self->thread_dispatch_disable_level;
if ( disable_level == 1 ) {
ISR_Level level;
@@ -272,12 +313,31 @@ RTEMS_INLINE_ROUTINE void _Thread_Enable_dispatch_body(
void )
}
/**
- * This routine allows dispatching to occur again. If this is
- * the outer most dispatching critical section, then a dispatching
- * operation will be performed and, if necessary, control of the
- * processor will be transferred to the heir thread.
+ * @brief Disables thread dispatching and acquires the Giant lock.
*/
+#if defined ( __THREAD_DO_NOT_INLINE_DISABLE_DISPATCH__ )
+void _Thread_Disable_dispatch( void );
+#else
+RTEMS_INLINE_ROUTINE void _Thread_Disable_dispatch( void )
+{
+ _Thread_Dispatch_increment_disable_level();
+ RTEMS_COMPILER_MEMORY_BARRIER();
+}
+#endif
+
+RTEMS_INLINE_ROUTINE void _Thread_Enable_dispatch_body( void )
+{
+ Per_CPU_Control *cpu_self = _Per_CPU_Get();
+
+ _Giant_Release( cpu_self );
+ _Thread_Dispatch_enable( cpu_self );
+}
+/**
+ * @brief Enables thread dispatching and releases the Giant lock.
+ *
+ * May perfrom a thread dispatch if necessary as a side-effect.
+ */
#if defined ( __THREAD_DO_NOT_INLINE_ENABLE_DISPATCH__ )
void _Thread_Enable_dispatch( void );
#else
@@ -290,11 +350,11 @@ RTEMS_INLINE_ROUTINE void _Thread_Enable_dispatch_body(
void )
#endif
/**
- * This routine allows dispatching to occur again. However,
- * no dispatching operation is performed even if this is the outer
- * most dispatching critical section.
+ * @brief Enables thread dispatching and releases the Giant lock.
+ *
+ * @warning A thread dispatch is not performed as a side-effect. Use this
+ * function with
*/
-
RTEMS_INLINE_ROUTINE void _Thread_Unnest_dispatch( void )
{
RTEMS_COMPILER_MEMORY_BARRIER();
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 7/8] score: Add thread wait flags
Update #2273.
---
cpukit/score/include/rtems/score/thread.h | 30 +
cpukit/score/include/rtems/score/threadimpl.h | 161 ++
cpukit/score/src/threadinitialize.c | 2 +
3 files changed, 193 insertions(+)
diff --git a/cpukit/score/include/rtems/score/thread.h
b/cpukit/score/include/rtems/score/thread.h
index 299bac6..4984949 100644
--- a/cpukit/score/include/rtems/score/thread.h
+++ b/cpukit/score/include/rtems/score/thread.h
@@ -21,6 +21,7 @@
#ifndef _RTEMS_SCORE_THREAD_H
#define _RTEMS_SCORE_THREAD_H
+#include
#include
#if defined(RTEMS_MULTIPROCESSING)
#include
@@ -262,6 +263,25 @@ typedef union {
} Thread_Wait_information_Object_argument_type;
/**
+ * @brief This type is able to contain several flags used to control the wait
+ * class and state of a thread.
+ *
+ * The mutually exclusive wait class flags are
+ * - @ref THREAD_WAIT_CLASS_EVENT,
+ * - @ref THREAD_WAIT_CLASS_SYSTEM_EVENT, and
+ * - @ref THREAD_WAIT_CLASS_OBJECT.
+ *
+ * The mutually exclusive wait state flags are
+ * - @ref THREAD_WAIT_STATE_INTEND_TO_BLOCK,
+ * - @ref THREAD_WAIT_STATE_BLOCKED,
+ * - @ref THREAD_WAIT_STATE_SATISFIED,
+ * - @ref THREAD_WAIT_STATE_TIMEOUT,
+ * - @ref THREAD_WAIT_STATE_INTERRUPT_SATISFIED, and
+ * - @ref THREAD_WAIT_STATE_INTERRUPT_TIMEOUT,
+ */
+typedef unsigned int Thread_Wait_flags;
+
+/**
* @brief Information required to manage a thread while it is blocked.
*
* This contains the information required to manage a thread while it is
@@ -288,6 +308,16 @@ typedef struct {
/** This field points to the thread queue on which this thread is blocked. */
Thread_queue_Control *queue;
+
+ /**
+ * @brief This field contains several flags used to control the wait class
+ * and state of a thread in case fine-grained locking is used.
+ */
+#if defined(RTEMS_SMP)
+ Atomic_Uint flags;
+#else
+ Thread_Wait_flags flags;
+#endif
} Thread_Wait_information;
/**
diff --git a/cpukit/score/include/rtems/score/threadimpl.h
b/cpukit/score/include/rtems/score/threadimpl.h
index 19c22bc..84c22f9 100644
--- a/cpukit/score/include/rtems/score/threadimpl.h
+++ b/cpukit/score/include/rtems/score/threadimpl.h
@@ -923,6 +923,167 @@ RTEMS_INLINE_ROUTINE bool _Thread_Owns_resources(
return owns_resources;
}
+/**
+ * @brief The initial thread wait flags value set by _Thread_Initialize().
+ */
+#define THREAD_WAIT_FLAGS_INITIAL 0x0U
+
+/**
+ * @brief Mask to get the thread wait state flags.
+ */
+#define THREAD_WAIT_STATE_MASK 0xffU
+
+/**
+ * @brief Indicates that the thread begins with the blocking operation.
+ *
+ * A blocking operation consists of an optional watchdog initialization and the
+ * setting of the appropriate thread blocking state with the corresponding
+ * scheduler block operation.
+ */
+#define THREAD_WAIT_STATE_INTEND_TO_BLOCK 0x1U
+
+/**
+ * @brief Indicates that the thread completed the blocking operation.
+ */
+#define THREAD_WAIT_STATE_BLOCKED 0x2U
+
+/**
+ * @brief Indicates that the thread progress condition is satisfied and it is
+ * ready to resume execution.
+ */
+#define THREAD_WAIT_STATE_SATISFIED 0x4U
+
+/**
+ * @brief Indicates that a timeout occurred and the thread is ready to resume
+ * execution.
+ */
+#define THREAD_WAIT_STATE_TIMEOUT 0x8U
+
+/**
+ * @brief Indicates that the thread progress condition was satisfied during the
+ * blocking operation and it is ready to resume execution.
+ */
+#define THREAD_WAIT_STATE_INTERRUPT_SATISFIED 0x10U
+
+/**
+ * @brief Indicates that a timeout occurred during the blocking operation and
+ * the thread is ready to resume execution.
+ */
+#define THREAD_WAIT_STATE_INTERRUPT_TIMEOUT 0x20U
+
+/**
+ * @brief Mask to get the thread wait class flags.
+ */
+#define THREAD_WAIT_CLASS_MASK 0xff00U
+
+/**
+ * @brief Indicates that the thread waits for an event.
+ */
+#define THREAD_WAIT_CLASS_EVENT 0x100U
+
+/**
+ * @brief Indicates that the thread waits for a system event.
+ */
+#define THREAD_WAIT_CLASS_SYSTEM_EVENT 0x200U
+
+/**
+ * @brief Indicates that the thread waits for a object.
+ */
+#define THREAD_WAIT_CLASS_OBJECT 0x400U
+
+RTEMS_INLINE_ROUTINE void _Thread_Wait_flags_set(
+ Thread_Control*the_thread,
+ Thread_Wait_flags flags
+)
+{
+#if defined(RTEMS_SMP)
+ _Atomic_Store_uint( &the_thread->Wait.flags, flags, ATOMIC_ORDER_RELAXED );
+#else
+ the_thread->Wait.flags = flags;
+#endif
+}
+
+RTEMS_INLINE_ROUTINE Thread_Wait_flags _Thread_Wait_flags_get(
+ const Thread_Control *the_thread
+)
+{
+#if defined(RTEMS_SMP)
+ return _Atomic_Load_uint( &the_thread->Wait.flags, ATOMIC_ORDER_RELAXED );
+#else
+ return the_thread->Wait.flags;
+#endif
+}
+
+/**
+ * @brief Tries to change the thread wait flags inside a critical section
+ * (interrupts disabled).
+ *
+ * In case the wait flags are equal to the expected wait flags, then the wait
+ * flags are set to the desired wait flags.
+ *
+ * @param[in] the_thread The thread.
+ * @param[in] expected_flags The e
[PATCH 3/8] score: Add and use _Thread_Do_dispatch()
The _Thread_Dispatch() function is quite complex and the time to set up
and tear down the stack frame is significant. Split this function into
two parts. The complex part is now in _Thread_Do_dispatch(). Call
_Thread_Do_dispatch() in _Thread_Enable_dispatch() only if necessary.
This increases the average case performance.
Simplify _Thread_Handler() for SMP configurations.
Update #2273.
---
cpukit/score/include/rtems/score/threaddispatch.h | 71 ++-
cpukit/score/src/threaddispatch.c | 64 ++--
cpukit/score/src/threadhandler.c | 70 ++
testsuites/tmtests/tm26/task1.c | 4 ++
4 files changed, 124 insertions(+), 85 deletions(-)
diff --git a/cpukit/score/include/rtems/score/threaddispatch.h
b/cpukit/score/include/rtems/score/threaddispatch.h
index aec436f..80de19d 100644
--- a/cpukit/score/include/rtems/score/threaddispatch.h
+++ b/cpukit/score/include/rtems/score/threaddispatch.h
@@ -193,26 +193,40 @@ RTEMS_INLINE_ROUTINE void
_Thread_Dispatch_initialization( void )
#endif /* RTEMS_SMP */
/**
- * @brief Dispatch thread.
+ * @brief Performs a thread dispatch if necessary.
*
- * This routine is responsible for transferring control of the
- * processor from the executing thread to the heir thread. Once the
- * heir is running an attempt is made to dispatch any ASRs.
- * As part of this process, it is responsible for the following actions:
- * + saving the context of the executing thread
- * + restoring the context of the heir thread
- * + dispatching any signals for the resulting executing thread
-
- * ALTERNATE ENTRY POINTS:
- *void _Thread_Enable_dispatch();
+ * This routine is responsible for transferring control of the processor from
+ * the executing thread to the heir thread. Once the heir is running an
+ * attempt is made to run the pending post-switch thread actions.
*
- * - INTERRUPT LATENCY:
- *+ dispatch thread
- *+ no dispatch thread
+ * As part of this process, it is responsible for the following actions
+ * - update timing information of the executing thread,
+ * - save the context of the executing thread,
+ * - invokation of the thread switch user extensions,
+ * - restore the context of the heir thread, and
+ * - run of pending post-switch thread actions of the resulting executing
+ * thread.
+ *
+ * On entry the thread dispatch level must be equal to zero.
*/
void _Thread_Dispatch( void );
/**
+ * @brief Performs a thread dispatch on the current processor.
+ *
+ * On entry the thread dispatch disable level must be equal to one and
+ * interrupts must be disabled.
+ *
+ * This function assumes that a thread dispatch is necessary.
+ *
+ * @param[in] cpu_self The current processor.
+ * @param[in] level The previous interrupt level.
+ *
+ * @see _Thread_Dispatch().
+ */
+void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level );
+
+/**
* This routine prevents dispatching.
*/
@@ -228,8 +242,33 @@ RTEMS_INLINE_ROUTINE void _Thread_Disable_dispatch( void )
RTEMS_INLINE_ROUTINE void _Thread_Enable_dispatch_body( void )
{
- if ( _Thread_Dispatch_decrement_disable_level() == 0 )
-_Thread_Dispatch();
+ Per_CPU_Control *cpu_self;
+ uint32_t disable_level;
+
+ cpu_self = _Per_CPU_Get();
+
+#if defined( RTEMS_SMP )
+ _Giant_Release( cpu_self );
+#endif
+
+ disable_level = cpu_self->thread_dispatch_disable_level;
+
+ if ( disable_level == 1 ) {
+ISR_Level level;
+
+_ISR_Disable_without_giant( level );
+
+if ( cpu_self->dispatch_necessary ) {
+ _Thread_Do_dispatch( cpu_self, level );
+} else {
+ cpu_self->thread_dispatch_disable_level = 0;
+ _Profiling_Thread_dispatch_enable( cpu_self, 0 );
+}
+
+_ISR_Enable_without_giant( level );
+ } else {
+cpu_self->thread_dispatch_disable_level = disable_level - 1;
+ }
}
/**
diff --git a/cpukit/score/src/threaddispatch.c
b/cpukit/score/src/threaddispatch.c
index cc023fc..f20f427 100644
--- a/cpukit/score/src/threaddispatch.c
+++ b/cpukit/score/src/threaddispatch.c
@@ -60,40 +60,15 @@ static void _Thread_Run_post_switch_actions( Thread_Control
*executing )
_Thread_Action_release_and_ISR_enable( cpu_self, level );
}
-void _Thread_Dispatch( void )
+void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
{
- Per_CPU_Control *cpu_self;
- Thread_Control *executing;
- ISR_Level level;
-
-#if defined( RTEMS_SMP )
- /*
- * On SMP the complete context switch must be atomic with respect to one
- * processor. See also _Thread_Handler() since _Context_switch() may branch
- * to this function.
- */
- _ISR_Disable_without_giant( level );
-#endif
+ Thread_Control *executing;
- cpu_self = _Per_CPU_Get();
- _Assert( cpu_self->thread_dispatch_disable_level == 0 );
- _Profiling_Thread_dispatch_disable( cpu_self, 0 );
- cpu_self->thread_dispatch_disable_level = 1;
+ _Assert(
[PATCH 6/8] score: Add thread acquire
Update #2273.
---
cpukit/score/include/rtems/score/threadimpl.h | 18 ++
cpukit/score/src/threadget.c | 85 +++
2 files changed, 79 insertions(+), 24 deletions(-)
diff --git a/cpukit/score/include/rtems/score/threadimpl.h
b/cpukit/score/include/rtems/score/threadimpl.h
index e5e51ec..19c22bc 100644
--- a/cpukit/score/include/rtems/score/threadimpl.h
+++ b/cpukit/score/include/rtems/score/threadimpl.h
@@ -398,6 +398,24 @@ Thread_Control *_Thread_Get (
);
/**
+ * @brief Acquires a thread by its identifier.
+ *
+ * @see _Objects_Acquire().
+ */
+Thread_Control *_Thread_Acquire(
+ Objects_Id id,
+ Objects_Locations *location,
+ ISR_lock_Context *lock_context
+);
+
+/**
+ * @brief Acquires the executing thread.
+ *
+ * @see _Objects_Acquire().
+ */
+Thread_Control *_Thread_Acquire_executing( ISR_lock_Context *lock_context );
+
+/**
* @brief Cancel a blocking operation due to ISR.
*
* This method is used to cancel a blocking operation that was
diff --git a/cpukit/score/src/threadget.c b/cpukit/score/src/threadget.c
index d95a7eb..1091333 100644
--- a/cpukit/score/src/threadget.c
+++ b/cpukit/score/src/threadget.c
@@ -21,34 +21,22 @@
#include
-Thread_Control *_Thread_Get (
- Objects_Id id,
- Objects_Locations *location
+static Objects_Information *_Thread_Get_objects_information(
+ Objects_Id id
)
{
uint32_t the_api;
uint32_t the_class;
Objects_Information **api_information;
- Objects_Information *information;
- Thread_Control *tp = (Thread_Control *) 0;
-
- if ( _Objects_Are_ids_equal( id, OBJECTS_ID_OF_SELF ) ) {
-_Thread_Disable_dispatch();
-*location = OBJECTS_LOCAL;
-tp = _Thread_Executing;
-goto done;
- }
the_api = _Objects_Get_API( id );
if ( !_Objects_Is_api_valid( the_api ) ) {
-*location = OBJECTS_ERROR;
-goto done;
+return NULL;
}
the_class = _Objects_Get_class( id );
if ( the_class != 1 ) { /* threads are always first class :) */
-*location = OBJECTS_ERROR;
-goto done;
+return NULL;
}
api_information = _Objects_Information_table[ the_api ];
@@ -59,19 +47,68 @@ Thread_Control *_Thread_Get (
* on in all configurations.
*/
if ( !api_information ) {
-*location = OBJECTS_ERROR;
-goto done;
+return NULL;
+ }
+
+ return api_information[ the_class ];
+}
+
+Thread_Control *_Thread_Get(
+ Objects_Id id,
+ Objects_Locations *location
+)
+{
+ Objects_Information *information;
+
+ if ( _Objects_Are_ids_equal( id, OBJECTS_ID_OF_SELF ) ) {
+_Thread_Disable_dispatch();
+*location = OBJECTS_LOCAL;
+return _Thread_Executing;
}
- information = api_information[ the_class ];
- if ( !information ) {
+ information = _Thread_Get_objects_information( id );
+ if ( information == NULL ) {
*location = OBJECTS_ERROR;
-goto done;
+return NULL;
}
- tp = (Thread_Control *) _Objects_Get( information, id, location );
+ return (Thread_Control *) _Objects_Get( information, id, location );
+}
+
+Thread_Control *_Thread_Acquire_executing( ISR_lock_Context *lock_context )
+{
+ Thread_Control *executing;
-done:
- return tp;
+#if defined(RTEMS_SMP)
+ _ISR_Disable_without_giant( lock_context->Lock_context.isr_level );
+#else
+ _ISR_Disable( lock_context->isr_level );
+#endif
+ executing = _Thread_Executing;
+ _ISR_lock_Acquire( &executing->Object.Lock, lock_context );
+
+ return executing;
}
+Thread_Control *_Thread_Acquire(
+ Objects_Id id,
+ Objects_Locations *location,
+ ISR_lock_Context *lock_context
+)
+{
+ Objects_Information *information;
+
+ if ( _Objects_Are_ids_equal( id, OBJECTS_ID_OF_SELF ) ) {
+*location = OBJECTS_LOCAL;
+return _Thread_Acquire_executing( lock_context );
+ }
+
+ information = _Thread_Get_objects_information( id );
+ if ( information == NULL ) {
+*location = OBJECTS_ERROR;
+return NULL;
+ }
+
+ return (Thread_Control *)
+_Objects_Acquire( information, id, location, lock_context );
+}
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Fine-grained locking for events
This patch set adds basic support for fine-grained locking on a per-object scope. The Giant lock is only used for the blocking operations (thread state, scheduler, watchdog). It uses the RTEMS events do demonstrate the basic functionality. The basic idea is to store the intermediate thread blocking states in the thread control block and not in global variables or thread queues. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?
Hello, why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC? You can say a lot about SPARC, but not that function calls are slow. Is it not better to reduce the code size and don't inline the _Thread_Enable_dispatch()? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Delete unused CPU_UNROLL_ENQUEUE_PRIORITY
---
cpukit/score/cpu/arm/rtems/score/cpu.h | 2 --
cpukit/score/cpu/avr/rtems/score/cpu.h | 24
cpukit/score/cpu/bfin/rtems/score/cpu.h| 23 ---
cpukit/score/cpu/h8300/rtems/score/cpu.h | 24
cpukit/score/cpu/i386/rtems/score/cpu.h| 1 -
cpukit/score/cpu/lm32/rtems/score/cpu.h| 23 ---
cpukit/score/cpu/m32c/rtems/score/cpu.h| 23 ---
cpukit/score/cpu/m32r/rtems/score/cpu.h| 23 ---
cpukit/score/cpu/m68k/rtems/score/cpu.h| 1 -
cpukit/score/cpu/mips/rtems/score/cpu.h| 20
cpukit/score/cpu/moxie/rtems/score/cpu.h | 23 ---
cpukit/score/cpu/nios2/rtems/score/cpu.h | 5 -
cpukit/score/cpu/no_cpu/rtems/score/cpu.h | 23 ---
cpukit/score/cpu/or1k/rtems/score/cpu.h| 21 -
cpukit/score/cpu/powerpc/rtems/score/cpu.h | 20
cpukit/score/cpu/sh/rtems/score/cpu.h | 20
cpukit/score/cpu/sparc/rtems/score/cpu.h | 16
cpukit/score/cpu/sparc64/rtems/score/cpu.h | 17 -
cpukit/score/cpu/v850/rtems/score/cpu.h| 24
19 files changed, 333 deletions(-)
diff --git a/cpukit/score/cpu/arm/rtems/score/cpu.h
b/cpukit/score/cpu/arm/rtems/score/cpu.h
index f0573c2..ca8a09f 100644
--- a/cpukit/score/cpu/arm/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/rtems/score/cpu.h
@@ -113,8 +113,6 @@
#error "unknown endianness"
#endif
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
/*
* The ARM uses the PIC interrupt model.
*/
diff --git a/cpukit/score/cpu/avr/rtems/score/cpu.h
b/cpukit/score/cpu/avr/rtems/score/cpu.h
index 7a6e9d9..fc5cc59 100644
--- a/cpukit/score/cpu/avr/rtems/score/cpu.h
+++ b/cpukit/score/cpu/avr/rtems/score/cpu.h
@@ -57,30 +57,6 @@ extern "C" {
#define CPU_INLINE_ENABLE_DISPATCH FALSE
/*
- * Should the body of the search loops in _Thread_queue_Enqueue_priority
- * be unrolled one time? In unrolled each iteration of the loop examines
- * two "nodes" on the chain being searched. Otherwise, only one node
- * is examined per iteration.
- *
- * If TRUE, then the loops are unrolled.
- * If FALSE, then the loops are not unrolled.
- *
- * The primary factor in making this decision is the cost of disabling
- * and enabling interrupts (_ISR_Flash) versus the cost of rest of the
- * body of the loop. On some CPUs, the flash is more expensive than
- * one iteration of the loop body. In this case, it might be desirable
- * to unroll the loop. It is important to note that on some CPUs, this
- * code is the longest interrupt disable period in RTEMS. So it is
- * necessary to strike a balance when setting this parameter.
- *
- * AVR Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-
-#define CPU_UNROLL_ENQUEUE_PRIORITY FALSE
-
-/*
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/bfin/rtems/score/cpu.h
b/cpukit/score/cpu/bfin/rtems/score/cpu.h
index 0b728e7..52fb3f8 100644
--- a/cpukit/score/cpu/bfin/rtems/score/cpu.h
+++ b/cpukit/score/cpu/bfin/rtems/score/cpu.h
@@ -54,29 +54,6 @@ extern "C" {
#define CPU_INLINE_ENABLE_DISPATCH FALSE
/**
- * Should the body of the search loops in _Thread_queue_Enqueue_priority
- * be unrolled one time? In unrolled each iteration of the loop examines
- * two "nodes" on the chain being searched. Otherwise, only one node
- * is examined per iteration.
- *
- * If TRUE, then the loops are unrolled.
- * If FALSE, then the loops are not unrolled.
- *
- * The primary factor in making this decision is the cost of disabling
- * and enabling interrupts (_ISR_Flash) versus the cost of rest of the
- * body of the loop. On some CPUs, the flash is more expensive than
- * one iteration of the loop body. In this case, it might be desirable
- * to unroll the loop. It is important to note that on some CPUs, this
- * code is the longest interrupt disable period in RTEMS. So it is
- * necessary to strike a balance when setting this parameter.
- *
- * Port Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/h8300/rtems/score/cpu.h
b/cpukit/score/cpu/h8300/rtems/score/cpu.h
index 334cfbd..56b3fdb 100644
--- a/cpukit/score/cpu/h8300/rtems/score/cpu.h
+++ b/cpukit/score/cpu/h8300/rtems/score/cpu.h
@@ -55,30 +55,6 @@ extern "C" {
#define CPU_INLINE_ENABLE_DISPATCH FALSE
/*
- * Should the body of the search loops in _Thread_queue_Enqueue_priority
- *
Re: [PATCH] tests: Refactor parallel test execution
OK. On Wed, Mar 4, 2015 at 9:22 AM, Sebastian Huber wrote: > > On 04/03/15 15:17, Gedare Bloom wrote: >> >> It seems that these changes to test.h and the new testparallel.c >> belong in the testsuites/smptests area, perhaps in a shared/ >> subdirectory. Certainly I don't see why testparallel.c is in sapi. (I >> don't recall why we have testing framework in the sapi though...) > > > The problem with this shared subdirectory in the testsuite area is that this > leads to copy and paste in the Makefiles and this is a maintenance > nightmare. We probably need a library for all tests. This is a build system > issue, which I would like to postpone after the waf integration. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] tests: Refactor parallel test execution
Would it at least make sense to add a subdirectory with a different name in cpukit? You could add libmisc/test_support and only have to add a few lines to libmisc/Makefile.am. That would contain this stuff better. On 3/4/2015 9:41 AM, Gedare Bloom wrote: > OK. > > On Wed, Mar 4, 2015 at 9:22 AM, Sebastian Huber > wrote: >> On 04/03/15 15:17, Gedare Bloom wrote: >>> It seems that these changes to test.h and the new testparallel.c >>> belong in the testsuites/smptests area, perhaps in a shared/ >>> subdirectory. Certainly I don't see why testparallel.c is in sapi. (I >>> don't recall why we have testing framework in the sapi though...) >> >> The problem with this shared subdirectory in the testsuite area is that this >> leads to copy and paste in the Makefiles and this is a maintenance >> nightmare. We probably need a library for all tests. This is a build system >> issue, which I would like to postpone after the waf integration. >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> Phone : +49 89 189 47 41-16 >> Fax : +49 89 189 47 41-09 >> E-Mail : sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/8] score: Update _Thread_Heir only if necessary
On 3/4/2015 9:07 AM, Sebastian Huber wrote:
> Previously, the _Thread_Heir was updated unconditionally in case a new
> heir was determined. The _Thread_Dispatch_necessary was only updated in
> case the executing thread was preemptible or an internal thread was
> unblocked. Change this to update the _Thread_Heir and
> _Thread_Dispatch_necessary only in case the currently selected heir
> thread is preemptible or a dispatch is forced. Move the schedule
> decision into the change priority operation and use the schedule
> operation only in rtems_task_mode() in case preemption is enabled or an
> ASR dispatch is necessary. This is a behaviour change. Previously, the
> RTEMS_NO_PREEMPT also prevented signal delivery in certain cases (not
> always). Now, signal delivery is no longer influenced by
> RTEMS_NO_PREEMPT. Since the currently selected heir thread is used to
> determine if a new heir is chosen, non-preemptible heir threads
> currently not executing now prevent a new heir. This may have an
> application impact, see change test tm04. Document this change in sp04.
>
> Update #2273.
...
> diff --git a/cpukit/score/src/schedulercbsunblock.c
> b/cpukit/score/src/schedulercbsunblock.c
> index 688253c..bd27aff 100644
> --- a/cpukit/score/src/schedulercbsunblock.c
> +++ b/cpukit/score/src/schedulercbsunblock.c
> @@ -79,10 +79,10 @@ Scheduler_Void_or_thread _Scheduler_CBS_Unblock(
> _Thread_Heir->current_priority
> )
>) {
> -_Thread_Heir = the_thread;
> -if ( _Thread_Executing->is_preemptible ||
> - the_thread->current_priority == 0 )
> - _Thread_Dispatch_necessary = true;
> +_Scheduler_Update_heir(
> + the_thread,
> + the_thread->current_priority == 0
> +);
The use of an expression without parentheses seems inconsistent
style-wise. I don't think this type of code is used often but could
you please put parentheses around this?
This same pattern is in other places so please do it globally across
this patch.
I think I spotted a total of four places.
Also since this indicates that the thread is at the pseudo-interrupt
priority,
maybe a macro/static inline with a meaningful name would be even
better.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/8] score: Update _Thread_Heir only if necessary
On Wed, Mar 4, 2015 at 10:42 AM, Joel Sherrill
wrote:
>
>
> On 3/4/2015 9:07 AM, Sebastian Huber wrote:
>> Previously, the _Thread_Heir was updated unconditionally in case a new
>> heir was determined. The _Thread_Dispatch_necessary was only updated in
>> case the executing thread was preemptible or an internal thread was
>> unblocked. Change this to update the _Thread_Heir and
>> _Thread_Dispatch_necessary only in case the currently selected heir
>> thread is preemptible or a dispatch is forced. Move the schedule
>> decision into the change priority operation and use the schedule
>> operation only in rtems_task_mode() in case preemption is enabled or an
>> ASR dispatch is necessary. This is a behaviour change. Previously, the
>> RTEMS_NO_PREEMPT also prevented signal delivery in certain cases (not
>> always). Now, signal delivery is no longer influenced by
>> RTEMS_NO_PREEMPT. Since the currently selected heir thread is used to
>> determine if a new heir is chosen, non-preemptible heir threads
>> currently not executing now prevent a new heir. This may have an
>> application impact, see change test tm04. Document this change in sp04.
>>
>> Update #2273.
> ...
>> diff --git a/cpukit/score/src/schedulercbsunblock.c
>> b/cpukit/score/src/schedulercbsunblock.c
>> index 688253c..bd27aff 100644
>> --- a/cpukit/score/src/schedulercbsunblock.c
>> +++ b/cpukit/score/src/schedulercbsunblock.c
>> @@ -79,10 +79,10 @@ Scheduler_Void_or_thread _Scheduler_CBS_Unblock(
>> _Thread_Heir->current_priority
>> )
>>) {
>> -_Thread_Heir = the_thread;
>> -if ( _Thread_Executing->is_preemptible ||
>> - the_thread->current_priority == 0 )
>> - _Thread_Dispatch_necessary = true;
>> +_Scheduler_Update_heir(
>> + the_thread,
>> + the_thread->current_priority == 0
>> +);
> The use of an expression without parentheses seems inconsistent
> style-wise. I don't think this type of code is used often but could
> you please put parentheses around this?
>
This conflicts with our coding conventions to avoid excess parens.
> This same pattern is in other places so please do it globally across
> this patch.
> I think I spotted a total of four places.
>
> Also since this indicates that the thread is at the pseudo-interrupt
> priority,
> maybe a macro/static inline with a meaningful name would be even
> better.
>
Yes a macro might be good for this test.
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available(256) 722-9985
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?
Because it has been that way since 1999? The only reason I can think would be to curtail register window side-effects if there are any. I doubt there would be. Gedare On Wed, Mar 4, 2015 at 10:10 AM, Sebastian Huber wrote: > Hello, > > why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC? You can say a > lot about SPARC, but not that function calls are slow. Is it not better to > reduce the code size and don't inline the _Thread_Enable_dispatch()? > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?
On 3/4/2015 9:52 AM, Gedare Bloom wrote: Because it has been that way since 1999? The only reason I can think would be to curtail register window side-effects if there are any. I doubt there would be. I doubt there would be any side-effects either. It can't add to the maximum stack depth and it is unlikely to trigger a window overflow since we probably just returned from another subroutine call. One issue issue is coverage. When building for coverage, _Thread_Enable_dispatch should not be inlined. My quick grep shows 85 calls in cpukit. When not inlined, it is one branch to test. When inlined, we get 170 paths and our current tests don't test but 85 of those. We have no tests which make any API calls with a lock held. This may change with the lock work but it probably just moves branches around and we will end up with new issues for branch explosion due to inlining. --joel Gedare On Wed, Mar 4, 2015 at 10:10 AM, Sebastian Huber wrote: Hello, why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC? You can say a lot about SPARC, but not that function calls are slow. Is it not better to reduce the code size and don't inline the _Thread_Enable_dispatch()? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] tests: Refactor parallel test execution
On 04/03/15 16:43, Joel Sherrill wrote: Would it at least make sense to add a subdirectory with a different name in cpukit? You could add libmisc/test_support and only have to add a few lines to libmisc/Makefile.am. That would contain this stuff better. Ok, good idea. We move the stuff to this directory. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/8] score: Update _Thread_Heir only if necessary
On 04/03/15 16:44, Gedare Bloom wrote:
On Wed, Mar 4, 2015 at 10:42 AM, Joel Sherrill
wrote:
On 3/4/2015 9:07 AM, Sebastian Huber wrote:
Previously, the _Thread_Heir was updated unconditionally in case a new
heir was determined. The _Thread_Dispatch_necessary was only updated in
case the executing thread was preemptible or an internal thread was
unblocked. Change this to update the _Thread_Heir and
_Thread_Dispatch_necessary only in case the currently selected heir
thread is preemptible or a dispatch is forced. Move the schedule
decision into the change priority operation and use the schedule
operation only in rtems_task_mode() in case preemption is enabled or an
ASR dispatch is necessary. This is a behaviour change. Previously, the
RTEMS_NO_PREEMPT also prevented signal delivery in certain cases (not
always). Now, signal delivery is no longer influenced by
RTEMS_NO_PREEMPT. Since the currently selected heir thread is used to
determine if a new heir is chosen, non-preemptible heir threads
currently not executing now prevent a new heir. This may have an
application impact, see change test tm04. Document this change in sp04.
Update #2273.
...
diff --git a/cpukit/score/src/schedulercbsunblock.c
b/cpukit/score/src/schedulercbsunblock.c
index 688253c..bd27aff 100644
--- a/cpukit/score/src/schedulercbsunblock.c
+++ b/cpukit/score/src/schedulercbsunblock.c
@@ -79,10 +79,10 @@ Scheduler_Void_or_thread _Scheduler_CBS_Unblock(
_Thread_Heir->current_priority
)
) {
-_Thread_Heir = the_thread;
-if ( _Thread_Executing->is_preemptible ||
- the_thread->current_priority == 0 )
- _Thread_Dispatch_necessary = true;
+_Scheduler_Update_heir(
+ the_thread,
+ the_thread->current_priority == 0
+);
The use of an expression without parentheses seems inconsistent
style-wise. I don't think this type of code is used often but could
you please put parentheses around this?
This conflicts with our coding conventions to avoid excess parens.
Yes, can we please avoid parentheses in case, since the comma operator
has the weakest precedence.
This same pattern is in other places so please do it globally across
this patch.
I think I spotted a total of four places.
Also since this indicates that the thread is at the pseudo-interrupt
priority,
maybe a macro/static inline with a meaningful name would be even
better.
Yes a macro might be good for this test.
Since we started this discussion. It seems that the MPCI thread is the
only thread with a priority of 0. Should this be #ifdef
RTEMS_MULTIPROCESSING? Looks otherwise like dead code. It is possible to
gain a priority of 0 via the priority ceiling protocol. Is this a bug?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?
Joel, I think we're talking about removing inlining here for SPARC. -Gedare On Wed, Mar 4, 2015 at 11:07 AM, Joel Sherrill wrote: > On 3/4/2015 9:52 AM, Gedare Bloom wrote: >> >> Because it has been that way since 1999? >> >> The only reason I can think would be to curtail register window >> side-effects if there are any. I doubt there would be. > > I doubt there would be any side-effects either. It can't add to the > maximum stack depth and it is unlikely to trigger a window overflow > since we probably just returned from another subroutine call. > > One issue issue is coverage. When building for coverage, > _Thread_Enable_dispatch > should not be inlined. My quick grep shows 85 calls in cpukit. When not > inlined, > it is one branch to test. When inlined, we get 170 paths and our current > tests > don't test but 85 of those. We have no tests which make any API calls with > a lock held. > > This may change with the lock work but it probably just moves branches > around > and we will end up with new issues for branch explosion due to inlining. > > --joel > >> Gedare >> >> On Wed, Mar 4, 2015 at 10:10 AM, Sebastian Huber >> wrote: >>> >>> Hello, >>> >>> why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC? You can say a >>> lot about SPARC, but not that function calls are slow. Is it not better >>> to >>> reduce the code size and don't inline the _Thread_Enable_dispatch()? >>> >>> -- >>> Sebastian Huber, embedded brains GmbH >>> >>> Address : Dornierstr. 4, D-82178 Puchheim, Germany >>> Phone : +49 89 189 47 41-16 >>> Fax : +49 89 189 47 41-09 >>> E-Mail : sebastian.hu...@embedded-brains.de >>> PGP : Public key available on request. >>> >>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?
On 3/4/2015 1:01 PM, Gedare Bloom wrote: > Joel, I think we're talking about removing inlining here for SPARC. -Gedare Agreed. And I thought the first paragraph said it was OK on the SPARC. The SPARC does have fast calls and we should not trigger a register window overflow since we likely called a method in the super core just before the enable dispatch. --joel > On Wed, Mar 4, 2015 at 11:07 AM, Joel Sherrill > wrote: >> On 3/4/2015 9:52 AM, Gedare Bloom wrote: >>> Because it has been that way since 1999? >>> >>> The only reason I can think would be to curtail register window >>> side-effects if there are any. I doubt there would be. >> I doubt there would be any side-effects either. It can't add to the >> maximum stack depth and it is unlikely to trigger a window overflow >> since we probably just returned from another subroutine call. >> >> One issue issue is coverage. When building for coverage, >> _Thread_Enable_dispatch >> should not be inlined. My quick grep shows 85 calls in cpukit. When not >> inlined, >> it is one branch to test. When inlined, we get 170 paths and our current >> tests >> don't test but 85 of those. We have no tests which make any API calls with >> a lock held. >> >> This may change with the lock work but it probably just moves branches >> around >> and we will end up with new issues for branch explosion due to inlining. >> >> --joel >> >>> Gedare >>> >>> On Wed, Mar 4, 2015 at 10:10 AM, Sebastian Huber >>> wrote: Hello, why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC? You can say a lot about SPARC, but not that function calls are slow. Is it not better to reduce the code size and don't inline the _Thread_Enable_dispatch()? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/8] score: Update _Thread_Heir only if necessary
On 3/4/2015 12:55 PM, Sebastian Huber wrote:
> On 04/03/15 16:44, Gedare Bloom wrote:
>> On Wed, Mar 4, 2015 at 10:42 AM, Joel Sherrill
>> wrote:
>>> On 3/4/2015 9:07 AM, Sebastian Huber wrote:
Previously, the _Thread_Heir was updated unconditionally in case a new
heir was determined. The _Thread_Dispatch_necessary was only updated in
case the executing thread was preemptible or an internal thread was
unblocked. Change this to update the _Thread_Heir and
_Thread_Dispatch_necessary only in case the currently selected heir
thread is preemptible or a dispatch is forced. Move the schedule
decision into the change priority operation and use the schedule
operation only in rtems_task_mode() in case preemption is enabled or an
ASR dispatch is necessary. This is a behaviour change. Previously, the
RTEMS_NO_PREEMPT also prevented signal delivery in certain cases (not
always). Now, signal delivery is no longer influenced by
RTEMS_NO_PREEMPT. Since the currently selected heir thread is used to
determine if a new heir is chosen, non-preemptible heir threads
currently not executing now prevent a new heir. This may have an
application impact, see change test tm04. Document this change in sp04.
Update #2273.
>>> ...
diff --git a/cpukit/score/src/schedulercbsunblock.c
b/cpukit/score/src/schedulercbsunblock.c
index 688253c..bd27aff 100644
--- a/cpukit/score/src/schedulercbsunblock.c
+++ b/cpukit/score/src/schedulercbsunblock.c
@@ -79,10 +79,10 @@ Scheduler_Void_or_thread _Scheduler_CBS_Unblock(
_Thread_Heir->current_priority
)
) {
-_Thread_Heir = the_thread;
-if ( _Thread_Executing->is_preemptible ||
- the_thread->current_priority == 0 )
- _Thread_Dispatch_necessary = true;
+_Scheduler_Update_heir(
+ the_thread,
+ the_thread->current_priority == 0
+);
>>> The use of an expression without parentheses seems inconsistent
>>> style-wise. I don't think this type of code is used often but could
>>> you please put parentheses around this?
>>>
>> This conflicts with our coding conventions to avoid excess parens.
> Yes, can we please avoid parentheses in case, since the comma operator
> has the weakest precedence.
Give Gedare a vote and we will go 2 out of 3. :)
>>> This same pattern is in other places so please do it globally across
>>> this patch.
>>> I think I spotted a total of four places.
>>>
>>> Also since this indicates that the thread is at the pseudo-interrupt
>>> priority,
>>> maybe a macro/static inline with a meaningful name would be even
>>> better.
>>>
>> Yes a macro might be good for this test.
> Since we started this discussion. It seems that the MPCI thread is the
> only thread with a priority of 0. Should this be #ifdef
> RTEMS_MULTIPROCESSING? Looks otherwise like dead code. It is possible to
> gain a priority of 0 via the priority ceiling protocol. Is this a bug?
>
No. The timer server has a default priority of 0 also.
I suppose if code called from the timer server used a priority ceiling
mutex,
then it could get an error. But you have to be careful of timer service
routines
anyway.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
disposition of #1394: scandir() fails due to MAXNAMELEN is incorrect
Ticket #1394 [1] has been fixed in newlib since 2013. A simple workaround patch is also available on the ticket and can be applied to the 4.10 toolchain if we need to fix this for the 4.10 release branch. Does anyone want this ticket fixed for 4.10? Gedare [1] https://devel.rtems.org/ticket/1394 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
API deprecation
We have ticket #2265 requesting to deprecate notepads. It was also suggested we deprecate per-task variables. Do we have an established procedure for how to deprecate an API? Does anyone have any objections? Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score/cpu/or1k: Add cpuatomic.h to fix broken build.
4e3d9a4d6c76fba8e31138d503f736405dafc213 broke or1k, cpuatomic.h has to be added to all architectures. --- cpukit/score/cpu/or1k/Makefile.am | 3 +-- cpukit/score/cpu/or1k/preinstall.am | 4 cpukit/score/cpu/or1k/rtems/score/cpuatomic.h | 14 ++ 3 files changed, 19 insertions(+), 2 deletions(-) create mode 100644 cpukit/score/cpu/or1k/rtems/score/cpuatomic.h diff --git a/cpukit/score/cpu/or1k/Makefile.am b/cpukit/score/cpu/or1k/Makefile.am index b9e00d3..89b603b 100644 --- a/cpukit/score/cpu/or1k/Makefile.am +++ b/cpukit/score/cpu/or1k/Makefile.am @@ -11,13 +11,12 @@ include_rtems_scoredir = $(includedir)/rtems/score include_rtems_score_HEADERS = include_rtems_score_HEADERS += rtems/score/cpu.h +include_rtems_score_HEADERS += rtems/score/cpuatomic.h include_rtems_score_HEADERS += rtems/score/cpu_asm.h include_rtems_score_HEADERS += rtems/score/types.h include_rtems_score_HEADERS += rtems/score/or1k.h include_rtems_score_HEADERS += rtems/score/or1k-utility.h - - noinst_LIBRARIES = libscorecpu.a libscorecpu_a_SOURCES = diff --git a/cpukit/score/cpu/or1k/preinstall.am b/cpukit/score/cpu/or1k/preinstall.am index f4d7153..6e15e20 100644 --- a/cpukit/score/cpu/or1k/preinstall.am +++ b/cpukit/score/cpu/or1k/preinstall.am @@ -31,6 +31,10 @@ $(PROJECT_INCLUDE)/rtems/score/cpu.h: rtems/score/cpu.h $(PROJECT_INCLUDE)/rtems $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/score/cpu.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/score/cpu.h +$(PROJECT_INCLUDE)/rtems/score/cpuatomic.h: rtems/score/cpuatomic.h $(PROJECT_INCLUDE)/rtems/score/$(dirstamp) + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/score/cpuatomic.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/score/cpuatomic.h + $(PROJECT_INCLUDE)/rtems/score/cpu_asm.h: rtems/score/cpu_asm.h $(PROJECT_INCLUDE)/rtems/score/$(dirstamp) $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/score/cpu_asm.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/score/cpu_asm.h diff --git a/cpukit/score/cpu/or1k/rtems/score/cpuatomic.h b/cpukit/score/cpu/or1k/rtems/score/cpuatomic.h new file mode 100644 index 000..598ee76 --- /dev/null +++ b/cpukit/score/cpu/or1k/rtems/score/cpuatomic.h @@ -0,0 +1,14 @@ +/* + * COPYRIGHT (c) 2012-2013 Deng Hengyi. + * + * The license and distribution terms for this file may be + * found in the file LICENSE in this distribution or at + * http://www.rtems.org/license/LICENSE. + */ + +#ifndef _RTEMS_SCORE_ATOMIC_CPU_H +#define _RTEMS_SCORE_ATOMIC_CPU_H + +#include + +#endif /* _RTEMS_SCORE_ATOMIC_CPU_H */ -- 2.1.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
an error about RTEMS compile when make
Hi , I am a chinese student learning RTEMS ,I meet an error when I compile the RTEMS source code under the cygwin . bellowed is the detail of the problem error and I think there also has something wrong in this place I hope you can fixed this problem for me and I will be very grateful,thank you best regards , truly yours My name : Asher Country : china E-mail : zxya1...@163.com___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
an error about RTEMS compile when make
Hi , I meet error257 when I compile the RTEMS source code.I want to know the error type and how to handle this error best regards , Asher ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: an error about RTEMS compile when make
You are going to have to provide more details. Host, target, configure command, cut and paste of the error with some context around it. On March 4, 2015 9:09:15 PM CST, zhengyazhou wrote: >Hi , >I meet error257 when I compile the RTEMS source code.I want to know the >error type and how to handle this error > > >best regards , >Asher --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re:Re: an error about RTEMS compile when make
Thank you for answering me,here is the details Host : MS windows and I use Cygwin for RTEMS development device : ARM based target I installed the Prebuild Toolset on Cygwin,then uncompress the RTEMS source code in the file C/Cygwin64/ then execute the following command in the Cygwin command line #export PATH=/opt/rtems-4.10/bin:$PATH #cd ~/rtems-4.10.2 #mkdir bulid #cd build #../configure --target=arm-rtems4.10 --disable-posix --disable-networking --disable-cxx --enable-rtemsbsp=csb337 --prefix=/opt/rtems-4.10 #make then comes the error make[2]: Entering directory '/rtems-4.10.2/build/arm-rtems4.10/c' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/rtems-4.10.2/build/arm-rtems4.10/c' Making all in csb337 make[2]: Entering directory '/rtems-4.10.2/build/arm-rtems4.10/c/csb337' make[2]: *** No rule to make target 'all'。 停止。 make[2]: Leaving directory '/rtems-4.10.2/build/arm-rtems4.10/c/csb337' Makefile:257: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/rtems-4.10.2/build/arm-rtems4.10/c' Makefile:275: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 above is all the information ,can you solve this problem ? best wishes Asher At 2015-03-05 11:38:25, "Joel Sherrill" wrote: >You are going to have to provide more details. Host, target, configure >command, cut and paste of the error with some context around it. > > >On March 4, 2015 9:09:15 PM CST, zhengyazhou wrote: >>Hi , >>I meet error257 when I compile the RTEMS source code.I want to know the >>error type and how to handle this error >> >> >>best regards , >>Asher > >--joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/8] score: Update _Thread_Heir only if necessary
On 04/03/15 20:24, Joel Sherrill wrote: This same pattern is in other places so please do it globally across >>>this patch. >>>I think I spotted a total of four places. >>> >>>Also since this indicates that the thread is at the pseudo-interrupt >>>priority, >>>maybe a macro/static inline with a meaningful name would be even >>>better. >>> >>Yes a macro might be good for this test. >Since we started this discussion. It seems that the MPCI thread is the >only thread with a priority of 0. Should this be #ifdef >RTEMS_MULTIPROCESSING? Looks otherwise like dead code. It is possible to >gain a priority of 0 via the priority ceiling protocol. Is this a bug? > No. The timer server has a default priority of 0 also. I suppose if code called from the timer server used a priority ceiling mutex, then it could get an error. But you have to be careful of timer service routines anyway. Ok, this was a bit difficult to see, since it was obscured by the RTEMS_SYSTEM_TASK attribute. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Add and use PRIORITY_PSEUDO_ISR
---
cpukit/rtems/src/timerserver.c | 2 +-
cpukit/score/include/rtems/score/priority.h | 7 +++
cpukit/score/src/mpci.c | 2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/cpukit/rtems/src/timerserver.c b/cpukit/rtems/src/timerserver.c
index ad32172..e4fe56f 100644
--- a/cpukit/rtems/src/timerserver.c
+++ b/cpukit/rtems/src/timerserver.c
@@ -481,7 +481,7 @@ rtems_status_code rtems_timer_initiate_server(
if ( !_RTEMS_tasks_Priority_is_valid( priority ) ) {
if ( priority != RTEMS_TIMER_SERVER_DEFAULT_PRIORITY )
return RTEMS_INVALID_PRIORITY;
-_priority = 0;
+_priority = PRIORITY_PSEUDO_ISR;
}
/*
diff --git a/cpukit/score/include/rtems/score/priority.h
b/cpukit/score/include/rtems/score/priority.h
index f10f731..0a772f6 100644
--- a/cpukit/score/include/rtems/score/priority.h
+++ b/cpukit/score/include/rtems/score/priority.h
@@ -58,6 +58,13 @@ typedef uint32_t Priority_Control;
/** This defines the highest (most important) thread priority. */
#define PRIORITY_MINIMUM 0
+/**
+ * @brief This defines the priority of pseudo-ISR threads.
+ *
+ * Examples are the MPCI and timer server threads.
+ */
+#define PRIORITY_PSEUDO_ISR PRIORITY_MINIMUM
+
/** This defines the default lowest (least important) thread priority. */
#if defined (CPU_PRIORITY_MAXIMUM)
#define PRIORITY_DEFAULT_MAXIMUM CPU_PRIORITY_MAXIMUM
diff --git a/cpukit/score/src/mpci.c b/cpukit/score/src/mpci.c
index e8a8ba2..a2acf89 100644
--- a/cpukit/score/src/mpci.c
+++ b/cpukit/score/src/mpci.c
@@ -112,7 +112,7 @@ void _MPCI_Create_server( void )
CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK +
_Configuration_MP_table->extra_mpci_receive_server_stack,
CPU_ALL_TASKS_ARE_FP,
-PRIORITY_MINIMUM,
+PRIORITY_PSEUDO_ISR,
false, /* no preempt */
THREAD_CPU_BUDGET_ALGORITHM_NONE,
NULL,/* no budget algorithm callout */
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
