From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4357DF76.5000000@domain.hid> Date: Thu, 20 Oct 2005 20:18:30 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc). References: <4357C3E1.1040701@domain.hid> <4357C9F7.2060808@domain.hid> <4357CF67.8080601@domain.hid> <4357D4D2.1030400@domain.hid> In-Reply-To: <4357D4D2.1030400@domain.hid> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org Jan Kiszka wrote: > Ignacio Garc=EDa P=E9rez wrote: >=20 >>Jan Kiszka wrote: >> >> >> >>>Ignacio Garc=EDa P=E9rez wrote: >>> >>> >>> >>> >>>>Hi, >>>> >>>>While porting my application, I noticed that all synchronization >>>>primitives locking calls take a relative timeout as a parameter, righ= t? >>>> >>>>Of course, I can get the current time, calculate the timeout interval= by >>>>substracting the current time from the desired timeout moment, and ca= ll >>>>the function. But wouldn't something like this be possible?: >>>> >>>>Suppose I want to wait on a semaphore until t=3D1000, and now=3D900. >>>> >>>>1- I get current time (900). >>>>2- I calculate the relative timeout as 1000-900 =3D 100 >>>>3- I call rt_sem_p(&mysem, 100); >>>> >>>>In the best case, no preemption will occur between steps 1 and 3, but= my >>>>thread will still be sleeping not until t=3D1000, but until some time >>>>later, t=3D1000+d, where d is the time used by the code in steps 1-3 = and >>>>into the native skin/nucleus. >>>> >>>>In the worst case, in addition to that, the thread will be preempted >>>>between steps 1 and 3. If it is preempted by another higher priority >>>>thread for, say, 50 ticks, and the call in step 3 is actually execute= d >>>>at t=3D950, the thread will be sleeping until t=3D1050+d, which may n= ot be >>>>acceptable. >>>> >>>>What do you think? >>>> =20 >>>> >>> >>>That's true, having to convert between absolute and relative time (and >>>vice versa) in interruptible contexts can cause problems if the >>>application is not prepared for it. >>> >>>The question is: do you really need that precise timeouts for >>>synchronisation primitives? >>> >> >>Yes I do. In my application, there is a free-run periodic execution >>thread that gets once in a while synchronized to an external event. >> >>This thread waits on a semaphore with an absolute timeout of t, does it= s >>work, calculates t =3D t + period and waits again on the semaphore. If = the >>external event signals the semaphore, the thread wakes up immediately >>and does some slightly different stuff. >> >>The thing is, I want the free-run thread to execute at 2 KHz, this is, >>every 5 ms. If I use a relative time, I face the problem I described. >> >>I guess I could get it working properly using a periodic thread, but I'= m >>sure it's not as simple (and does not "feel" as natural) as just waitin= g >>on the synchronization primitive using an absolute timeout. >=20 >=20 > I see. >=20 >=20 >>I really really think there should be, for each call that takes a >>timeout, two version, one that takes a relative timeout and another tha= t >>takes an absolute timeout. >> >>Any chances of this being implemented in the current native API? >> >=20 >=20 > In kernel mode, you can already implement such version on your own. Tak= e > a look at the RTDM_EXECUTE_ATOMICALLY() macro (see RTDM->Driver > Development API->Synchronisation Services - or rtdm_driver.h). It shoul= d > demonstrate how to run the relative timeout calculation and the rt_sem_= p > call atomically (i.e. by taking the global nucleus lock already before > the service calls). >=20 One would only need local IRQ masking in Ignacio's case, using the SMP lo= ck=20 would be overkill. > Jan >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help --=20 Philippe.