[PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

Utkarsh Rai utkarsh.rai60 at gmail.com
Wed Aug 12 23:39:52 UTC 2020 

Hello Joel,
I had sent a v3 patch
https://lists.rtems.org/pipermail/devel/2020-April/059603.html, but it
somehow went unnoticed. This may need a bit of fine-tuning, and I plan to
pursue it after my GSoC ends (I have too many things on my plate right now
:))

On Thu, Aug 13, 2020 at 3:46 AM Joel Sherrill <joel at rtems.org> wrote:

> What's the status of this test? The last email seems to indicate it needed
> further work before being merged.
>
> On Wed, Apr 15, 2020 at 9:16 AM Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Wed, Apr 15, 2020 at 9:11 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> On Tue, Apr 14, 2020 at 10:56 PM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de> wrote:
>>> >
>>> > Hello Utkarsh Rai,
>>> >
>>> > do we really need a new test program for this test case? I would prefer
>>> > add it to an existing test program or add a generic POSIX test program
>>> > using the RTEMS Test Framework.
>>> >
>>> I would also recommend this, or perhaps develop a test for clock
>>> monotonic that encompasses several features (as done with clock
>>> realtime).
>>>
>>
>> In theory, the clock monotonic test could be the clock realtime one
>> reused
>> with the clock type changed. There are a few cases of doing something
>> similar.
>> The behavior is supposed to be the same for delays.
>>
>> Missing in this discussion and maybe what Gedare is hinting at is that you
>> any sleep/delay/etc type of operation is never specified as a precise
>> delay,
>> it is a minimum delay. The minimum may be set by clock tick time quantum,
>> other threads, processes, etc. The POSIX standard has precise language
>> about this for clock_nanosleep. From
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
>>
>> "The suspension time caused by this function may be longer than requested
>> because the argument value is rounded up to an integer multiple of the
>> sleep resolution, or because of the scheduling of other activity by the
>> system."
>>
>> --joel
>>
>>
>>> > On 14/04/2020 19:17, Utkarsh Rai wrote:
>>> > > This test checks for a simple 1 ns delay with clock_nanosleep with
>>> > > CLOCK_MONOTONIC.
>>> > > ---
>>> > >   testsuites/psxtests/Makefile.am               |  9 +++
>>> > >   testsuites/psxtests/configure.ac              |  1 +
>>> > >   .../psxtests/psxclocknanosleep01/init.c       | 81
>>> +++++++++++++++++++
>>> > >   .../psxclocknanosleep01.doc                   | 10 +++
>>> > >   .../psxclocknanosleep01.scn                   |  3 +
>>> > >   5 files changed, 104 insertions(+)
>>> > >   create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
>>> > >   create mode 100644
>>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
>>> > >   create mode 100644
>>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
>>> > >
>>> > > diff --git a/testsuites/psxtests/Makefile.am
>>> b/testsuites/psxtests/Makefile.am
>>> > > index 1f9e4233ec..e3918ae7a5 100755
>>> > > --- a/testsuites/psxtests/Makefile.am
>>> > > +++ b/testsuites/psxtests/Makefile.am
>>> > > @@ -321,6 +321,15 @@ psxclockrealtime01_CPPFLAGS = $(AM_CPPFLAGS) \
>>> > >       $(TEST_FLAGS_psxclockrealtime01) $(support_includes)
>>> > >   endif
>>> > >
>>> > > +if TEST_psxclocknanosleep01
>>> > > +psx_tests += psxclocknanosleep01
>>> > > +psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
>>> > > +psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
>>> > > +psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
>>> > > +psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) \
>>> > > +     $(TEST_FLAGS_psxclocknanosleep01) $(support_includes)
>>> > > +endif
>>> > > +
>>> > >   if TEST_psxconcurrency01
>>> > >   psx_tests += psxconcurrency01
>>> > >   psx_screens += psxconcurrency01/psxconcurrency01.scn
>>> > > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
>>> configure.ac
>>> > > index 139787cccb..9bfe8e2c0b 100644
>>> > > --- a/testsuites/psxtests/configure.ac
>>> > > +++ b/testsuites/psxtests/configure.ac
>>> > > @@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
>>> > >   RTEMS_TEST_CHECK([psxcleanup02])
>>> > >   RTEMS_TEST_CHECK([psxclock])
>>> > >   RTEMS_TEST_CHECK([psxclock01])
>>> > > +RTEMS_TEST_CHECK([psxclocknanosleep01])
>>> > >   RTEMS_TEST_CHECK([psxclockrealtime01])
>>> > >   RTEMS_TEST_CHECK([psxconcurrency01])
>>> > >   RTEMS_TEST_CHECK([psxcond01])
>>> > > diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c
>>> b/testsuites/psxtests/psxclocknanosleep01/init.c
>>> > > new file mode 100644
>>> > > index 0000000000..21b738627d
>>> > > --- /dev/null
>>> > > +++ b/testsuites/psxtests/psxclocknanosleep01/init.c
>>> > > @@ -0,0 +1,81 @@
>>> > > +/*
>>> > > + * SPDX-License-Identifier: BSD-2-Clause
>>> > > + *
>>> > > + * Copyright (C) 2020 Utkarsh Rai
>>> > > + *
>>> > > + * Redistribution and use in source and binary forms, with or
>>> without
>>> > > + * modification, are permitted provided that the following
>>> conditions
>>> > > + * are met:
>>> > > + * 1. Redistributions of source code must retain the above copyright
>>> > > + *    notice, this list of conditions and the following disclaimer.
>>> > > + * 2. Redistributions in binary form must reproduce the above
>>> copyright
>>> > > + *    notice, this list of conditions and the following disclaimer
>>> in the
>>> > > + *    documentation and/or other materials provided with the
>>> distribution.
>>> > > + *
>>> > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>>> CONTRIBUTORS "AS IS"
>>> > > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>> LIMITED TO, THE
>>> > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
>>> PARTICULAR PURPOSE
>>> > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
>>> CONTRIBUTORS BE
>>> > > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
>>> OR
>>> > > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
>>> PROCUREMENT OF
>>> > > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>>> BUSINESS
>>> > > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>>> WHETHER IN
>>> > > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>>> OTHERWISE)
>>> > > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
>>> ADVISED OF THE
>>> > > + * POSSIBILITY OF SUCH DAMAGE.
>>> > > + */
>>> > > +
>>> > > +#include <rtems.h>
>>> > > +#include <rtems/test.h>
>>> > > +#include <time.h>
>>> > > +#include <tmacros.h>
>>> > > +
>>> > > +/*Forward declaration to avoid compiler warning*/
>>> > > +void clock_sleep(void);
>>> > Please use a static function instead. Most of these forward
>>> declarations
>>> > are just lazy warning fixes and bad examples.
>>> > > +
>>> > > +rtems_task Init(rtems_task_argument ignored);
>>> > > +
>>> > > +const char rtems_test_name[] = "PSXCLOCKNANOSLEEP 01";
>>> > > +
>>> > > +void clock_sleep(void)
>>> > > +{
>>> > > +  struct timespec delay_time;
>>> > > +  int    status;
>>> > > +
>>> > > +  delay_time.tv_sec = 0;
>>> > > +  delay_time.tv_nsec = 1;
>>> > > +
>>> > > +  status=clock_nanosleep( CLOCK_MONOTONIC, 0, &delay_time, (struct
>>> timespec* )NULL );
>>> > In C code this cast is superfluous, in C++ code using NULL is out
>>> dated.
>>> > > +  rtems_test_assert( status == 0 );
>>> > > +}
>>> > > +
>>> > > +rtems_task Init(rtems_task_argument ignored)
>>> > > +{
>>> > > +
>>> > > +  struct timespec init_time;
>>> > > +  struct timespec end_time;
>>> > > +  int    status;
>>> > > +
>>> > > +  TEST_BEGIN();
>>> > > +
>>> > > +  status = clock_gettime( CLOCK_MONOTONIC, &init_time );
>>> > > +  rtems_test_assert( status == 0 );
>>> > > +
>>> > > +  clock_sleep();
>>> > > +
>>> > > +  status = clock_gettime( CLOCK_MONOTONIC, &end_time );
>>> > > +  rtems_test_assert( status == 0 );
>>> > > +
>>> > > +  rtems_test_assert( (end_time.tv_sec-init_time.tv_sec) == 0 );
>>> >
>>> > Is end_time.tv_sec - init_time.tv_sec == 0 under all circumstances?
>>> >
>>> > The test case code should be separated from the test suite boilerplate
>>> code.
>>> >
>>> > > +  rtems_test_assert( (end_time.tv_nsec-init_time.tv_nsec) >=1 );
>>> > We really should think about using a C code formatter. I think that I
>>> > waste my time telling someone to put spaces between operators.
>>> > _______________________________________________
>>> > devel mailing list
>>> > devel at rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200813/89177320/attachment.html>

More information about the devel mailing list