Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
On Mon, 2006-08-21 at 19:45 +0200, Dmitry Adamushko wrote: > > > On 21/08/06, Philippe Gerum <[EMAIL PROTECTED]> wrote: > On Mon, 2006-08-21 at 10:36 +0200, Dmitry Adamushko wrote: > > > [ timer.c.patch] xnticks_t is unsigned while (as I > understand) > > "xntlholder_date(&timer->plink) - nkpod->jiffies" can be > negative. > > ok, I somehow missed a check for xntimer_running_p() in > xntimer_get_timeout(). I bet it was not there when I was looking at > this part of code yesterday or maybe I just had too much u > wonderful belgium beer :o) It's been there since the fusion times! Ok, it must be the beer... :o> > > Actually xntimer_get_timeout() should be called with nklock held + irq > off as it must be atomic. But anyway, this is how it's used in all > places and it's probably not supposed to be used "as is" from any > upper layer. So it's ok. > Indeed. > > > -- > Best regards, > Dmitry Adamushko -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
On 21/08/06, Philippe Gerum <[EMAIL PROTECTED] > wrote: On Mon, 2006-08-21 at 10:36 +0200, Dmitry Adamushko wrote:> [ timer.c.patch] xnticks_t is unsigned while (as I understand)> "xntlholder_date(&timer->plink) - nkpod->jiffies" can be negative. ok, I somehow missed a check for xntimer_running_p() in xntimer_get_timeout(). I bet it was not there when I was looking at this part of code yesterday or maybe I just had too much u wonderful belgium beer :o) Actually xntimer_get_timeout() should be called with nklock held + irq off as it must be atomic. But anyway, this is how it's used in all places and it's probably not supposed to be used "as is" from any upper layer. So it's ok. -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
On Mon, 2006-08-21 at 13:47 +0200, Dmitry Adamushko wrote: > From: > Dmitry Adamushko > <[EMAIL PROTECTED]> >To: > xenomai-core@gna.org > Subject: > [Xenomai-core] [patch, minor] > xnpipe_recv and > xntimer_get_timeout_periodic() > Date: > Mon, 21 Aug 2006 13:47:00 +0200 > > > > > > On Mon, 2006-08-21 at 12:47 +0200, Dmitry Adamushko wrote: > > > > what about pipe-related change (I mean timeslice updating > in > > xnpipe_recv()) ? > > > > It's basically useless, since xnsynch_sleep_on() handles the > resource > stealing case internally, and the loop in xnpipe_recv is fake > actually. > Think of it as a goto statement in disguise. > > It has nothing to do with "resource stealing" (in terms of synch.c). > The synch object is not PIP at all. > Ok, I thought we were discussing a more general issue about a new potential side-effect of the resource stealing feature. > task1 : blocked in xnpipe_recv() > > task2 : xnpipe_send() ---> wakes up task1 ---> task1 is waiting to be > scheduled in > > task3 [prio > task2.prio] : gets CPU and calls xnpipe_recv() > >task3 gets a message so state->inq is empty now. > > ... > > task2 : calls getq(&state->inq) which is NULL now (if there were no > more messages) > > calls xnsynch_sleep_on() again with the initial "timeout". > Definitely, yes. Please ignore my previous comment. I'll apply this one, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
On Mon, 2006-08-21 at 12:47 +0200, Dmitry Adamushko wrote: > > what about pipe-related change (I mean timeslice updating in > xnpipe_recv()) ? > It's basically useless, since xnsynch_sleep_on() handles the resource stealing case internally, and the loop in xnpipe_recv is fake actually. Think of it as a goto statement in disguise. > > -- > Best regards, > Dmitry Adamushko -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
what about pipe-related change (I mean timeslice updating in xnpipe_recv()) ?-- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
On Mon, 2006-08-21 at 10:36 +0200, Dmitry Adamushko wrote: > > [ pipe.c.patch ] update the "timeout" variable so that the remaining > timeout is used in case of consequent xnsynch_sleep_on() calls. > > As I understand that may indeed happen in case when another thread > "steals" data while this one waits to be scheduled in. Indeed, but this case is already handled in xnsynch_sleep_on() (see the test for the XNROBBED bit). -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
On Mon, 2006-08-21 at 10:36 +0200, Dmitry Adamushko wrote: > [ timer.c.patch] xnticks_t is unsigned while (as I understand) > "xntlholder_date(&timer->plink) - nkpod->jiffies" can be negative. Well, normally, it should not. In periodic mode, each and every tick is processed by the timer handler which also maintains the time base (nkpod->jiffies), and as such, no timer should remain outstanding after its wakeup time has elapsed, otherwise, something is broken in the timer wheel management in the first place. IOW, we should never miss a tick, and consequently, negative timeouts cannot exist, since a timer is either running (= 0), or scheduled to elapse in the future (> 0). On the contrary, aperiodic mode is based on some free running TSC value not controlled by the nucleus, and as such, we might well ask for the timeout value slightly before the related timer elapses, and end up reading the TSC a bit later than its timeout date. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch, minor] xnpipe_recv and xntimer_get_timeout_periodic()
On Mon, 2006-08-21 at 10:36 +0200, Dmitry Adamushko wrote: > Not sure 1 should be returned in this case (so far I just did it the > same way as xntimer_get_timeout_aperiodic()), I guess 0 would be > better in both cases. Zero (XN_INFINITE) is reserved to indicate a non-running timer. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
