Re: rt_sem_wait_timed block too short

Hi Paolo,

That is perfect, thank you for your help. Comparing the return from rt_sem_wait_timed with RTE_TIMOUT works for me exactly as you described.

I completely missed this because the return of RTE_TIMOUT (0xFFFE on my system) is not mentioned in the documentation and I missed it when I first looked in the source: it seemed to me that just the semaphore count was being returned. I see it now.

Thanks again for your help.

Cheers,

John.

-----Original Message-----
From: Paolo Mantegazza [mailto:[email protected]]
Sent: 08 December 2015 13:32
To: John Wilkes; [email protected]
Cc: John Sahadat; Andrew Barnes
Subject: RE: rt_sem_wait_timed block too short

Rt_sem_wait_timed does return RTE_TIMOUT if that is the case. From its code one should notice that it is just:
RTAI_SYSCALL_MODE int rt_sem_wait_timed(SEM *sem, RTIME delay) {
        return rt_sem_wait_until(sem, get_time() + delay); } i.e it changes the relative time into its corresponding absolute value, then calling and returning what  rt_sem_wait_until returns.

Therefore RTE_TIMOUT should be returned in the case of a timeout.

In fact after including  the following flying "do no harm" test in any RTAI program:
{
        SEM *sem = rt_sem_init(0xcacca ,0);
        printf("IF %d IS 1 THEN A TIMEOUT OCCURED.\n", rt_sem_wait_timed(sem, nano2count(1000000000)) == RTE_TIMOUT);
       rt_sem_delete(sem);
}
I get:
IF 1 IS 1 THEN A TIMEOUT OCCURED.

So if it is not so in you application we should understand and fix a missing error comprehensiveness in rt_sem_wait_until.

Paolo
________________________________________
From: Rtai [[email protected]] on behalf of John Wilkes [[email protected]]
Sent: Tuesday, December 8, 2015 10:11 AM
To: [email protected]
Cc: John Sahadat; Andrew Barnes
Subject: [Rtai] rt_sem_wait_timed block too short

Hello RTAIers,

RTAI version 4.0 and Linux kernel 3.8.13

I have noticed a possible issue in the rt_sem_wait_timed function. There is no return from this function that indicates that a time out occurred rather than the semaphore being acquired. Therefore, I have wrapped the call in a function that effectively measures how long the call blocks for and if this is equal to or longer than the specified period, a time out is assumed. The code of this wrapper function is shown below (note that the semaphore is being posted by an interrupt handler in a kernel module, but that is kind of irrelevant since my problem is to do with when it doesn't get posted):

int32_t waitForInterrupt(SEM * sem, uint32_t timeOut) {
      /* Set time out in counts */
      RTIME timeOutCts = nano2count(timeOut*1000000);

      /* Wait for a semaphore indicating an interrupt event. */
      RTIME startTime = rt_get_time();
      rt_sem_wait_timed(sem, timeOutCts);
      RTIME elapsedTime = rt_get_time() - startTime;

      /* Report */
      if (elapsedTime >= timeOutCts) {
            /* Must have timed out */
            return 0;
      }
      else {
            /* Interrupt occurred */
            return 1;
      }
}

The problem is that occasionally elapsedTime is slightly less than the time out value. The amount varies but is typically of the order of 100ns, and so sometimes an interrupt that never occurred is detected. I have 'fixed' this in my code by assuming a time out if elapsedPeriod is within 1us of the specified period. I.e. modified the above code with this:
      ...
      /* Report */
      RTIME oneMicrosecondCts = nano2count(1000);
      if (elapsedTime >= (timeOutCts-oneMicrosecondCts)) {
            /* Must have timed out */
      ...

This fixes things for me, but I can't help thinking that there is a problem here in that the rt_sem_wait_function should really be blocking for at least as long as the specified period. It is only off by a very short amount so I wonder if there is some rounding going on somewhere. A better solution would be for this function to offer some sort of return that indicated a time out.

Cheers

John Wilkes
--------------------------------------------------------------------------------------------------
This email and any attachments are confidential and are for the use of the addressee only. If you are not the addressee, you must not use or disclose the contents to any other person. Please immediately notify the sender and delete the email. Statements and opinions expressed here may not represent those of the company. Email correspondence is monitored by the company. This information may be subject to export control regulation. You are obliged to comply with such regulations.

Renishaw plc (company number 1106260) and Wotton Travel Limited (company number 01973158) are companies registered in England and Wales with a registered office at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, United Kingdom, Telephone +44 1453 524524.
--------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------
This email and any attachments are confidential and are for the use of the
addressee only. If you are not the addressee, you must not use or disclose the
contents to any other person. Please immediately notify the sender and
delete the email. Statements and opinions expressed here may not
represent those of the company. Email correspondence is monitored by
the company. This information may be subject to export control
regulation. You are obliged to comply with such regulations.

Renishaw plc (company number 1106260) and Wotton Travel Limited (company
number 01973158) are companies registered in England and Wales with a registered office
at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR,
United Kingdom, Telephone +44 1453 524524.
--------------------------------------------------------------------------------------------------
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai