[RTEMS Project] #2811: More robust thread dispatching on SMP and ARM Cortex-M
RTEMS trac
trac at rtems.org
Wed Nov 16 06:17:31 UTC 2016
#2811: More robust thread dispatching on SMP and ARM Cortex-M
-----------------------------+------------------------------
Reporter: sebastian.huber | Owner: sebastian.huber
Type: enhancement | Status: new
Priority: normal | Milestone: 4.12
Component: cpukit | Version: 4.11
Severity: normal | Resolution:
Keywords: |
-----------------------------+------------------------------
Comment (by sebastian.huber):
I think a fatal error is more appropriate here.
* Applications which have this usage error needs to be fixed at compile-
time. It makes no sense to ship an SMP application with this bug.
* Return codes can be ignored. I definitely have seen code like this
before:
{{{
#!c
/* This cannot fail, we know the identifier is valid */
(void) pthread_mutex_lock(&mtx);
}}}
* This ticket is a result of porting a real world application from uni-
processor to SMP. If you are not an expert of the operating system
internals and your application has this bug, then you need easily a couple
of days to figure out the problem. So, it is important to make sure it
gets detected.
* To figure out what caused a fatal error is easy. The (source, error)
pair uniquely identifies the source code location of the error. With a
stack trace and the executing thread you get enough information to locate
the problem in the code. There is no need for a thread aware debugger.
* This is a new constraint specific to SMP. Existing software may be
simply unaware of this issue. However, its important to detect this
constraint violation.
* _Thread_Do_dispatch() has no return value. Adding this check to other
places would be much more difficult, error prone. with more space and time
overhead, and labour intensive to test.
--
Ticket URL: <http://devel.rtems.org/ticket/2811#comment:4>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list