From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4357D4D2.1030400@domain.hid> Date: Thu, 20 Oct 2005 19:33:06 +0200 From: Jan Kiszka 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> In-Reply-To: <4357CF67.8080601@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1545FBFBC381B3CCA716763D" List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Ignacio_Garc=EDa_P=E9rez?= Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1545FBFBC381B3CCA716763D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Ignacio Garc=EDa P=E9rez wrote: > Jan Kiszka wrote: >=20 >=20 >>Ignacio Garc=EDa P=E9rez wrote: >>=20 >> >> >>>Hi, >>> >>>While porting my application, I noticed that all synchronization >>>primitives locking calls take a relative timeout as a parameter, right= ? >>> >>>Of course, I can get the current time, calculate the timeout interval = by >>>substracting the current time from the desired timeout moment, and cal= l >>>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 a= nd >>>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 executed= >>>at t=3D950, the thread will be sleeping until t=3D1050+d, which may no= t 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? >> >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. I see. >=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. >=20 > Any chances of this being implemented in the current native API? >=20 In kernel mode, you can already implement such version on your own. Take a look at the RTDM_EXECUTE_ATOMICALLY() macro (see RTDM->Driver Development API->Synchronisation Services - or rtdm_driver.h). It should 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). Jan --------------enig1545FBFBC381B3CCA716763D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV9TSncNeS9Q0k+IRAi/tAJ9uroZ9WiWxu9anP9aYfGMPAQXbvgCfdtTz y2poibilDnN1i/U7AdUGEig= =wWsM -----END PGP SIGNATURE----- --------------enig1545FBFBC381B3CCA716763D--