Re: rt_sem_wait_timed block too short

On 12/09/2015 10:20 AM, John Wilkes wrote:
> 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.
In fact we have a sketchy documentation through the "help" button 
associated to the RTAI menuconfig items.
I know it is something rough but ... something is still better than nothing.
I suggest enabling the option of using the new return values, under 
"Other features". It is the not default one, to avoid problems to very 
old unchanged legacy  RTAI applications.
Nevertheless, also because of your case, I'll make it the default from 
5.0 onward. Very old RTAI users will have to adapt. Saving legacy 
features with newer update can became a maintainer mess.

Paolo
> 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