[PATCH 3/3] smpschedsem01: New test Test to verify task priority is inherited from a semaphore.

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Jun 16 07:02:32 UTC 2014

On 2014-06-13 17:29, Joel Sherrill wrote:
> On 6/12/2014 8:06 AM, Sebastian Huber wrote:
>> On 2014-06-11 21:18, jennifer wrote:
>>> +++ b/testsuites/smptests/smpschedsem01/smpschedsem01.doc
>>> @@ -0,0 +1,11 @@
>>> +This file describes the directives and concepts tested by this test set.
>>> +
>>> +test set name: smpschedaffinity01
>>> +
>>> +directives:
>>> +
>>> +  - XXX
>>> +
>>> +concepts:
>>> +
>>> +  - Ensure that affinity is honored at task start.
>> This file doesn't match with the subject.  What is the purpose of this test?
>> If you want to test the change priority operation, then you may have a look at:
>> http://git.rtems.org/rtems/tree/testsuites/smptests/smpscheduler03/init.c
> Why are you testing at the Score API level?
> Tests should not be written which violate the public APIs unless there
> is a VERY VERY good reason.

It is very difficult to test these state changes with a test using only the 
public API.  For the ready to scheduled state changes you need interrupts. 
Only one state change is impossible in a real system, that is ready to 
scheduled with prepend.

> Again, this is another one of those unwritten rules but when you do
> that, there is no proof that the method, argument combination,
> or mode is needed by any API. For example, if you have code in the
> Score which can only be accessed from POSIX and you test directly,
> there is no way from the coverage data to tell that the method
> is not needed when POSIX is disabled. Or that the method isn't
> needed at all.
> The only normal paths to _Thread_Change_priority with
> prepend_it set to FALSE is through the core mutex. Which means
> you need to either initialize a mutex the correct way or
> surrender one restoring your priority.
> Code is either needed in support of an API or serves no purpose.
> Unit testing at the Score level makes unnecessary code harder to
> find and violates the API boundary.

For the code coverage metric this test is worthless, but for a correctness test 
of the implementation it is valuable.  I think we need at least two sets of 
tests, one that targets code coverage and one that simply test the correctness 
of the basic implementation.

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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list