rtems_event_receive() return code question

Sergei Organov osv at topconrd.ru
Mon Feb 2 17:53:03 UTC 2004


"Thomas Rauscher" <trauscher at loytec.com> writes:
> > -----Original Message-----
> > From: Sergei Organov [mailto:osv at topconrd.ru] 
> > "Thomas Rauscher" <trauscher at loytec.com> writes:
> > > Hi,
> > > 
> > > I've a question regarding the rtems_event_receive() semantics.
> > > The API documentation unfortunately leaves some open questions.
> > > 
> > > If a rtems_event_receive() function is called with timeout, but
> > > receives events just while returning after a timeout, is it 
> > > correct to
> > > return RTEMS_TIMEOUT but have the event_out parameter set to
> > > a satisfying event set?
> > 
> > While not explicitly documented, the 'event_out' is left untouched when
> > RTEMS_TIMEOUT is returned. Thus, you need to initialize it to 0 before
> > calling rtems_event_receive() (it's almost always a good idea to 
> > initialize all your variables anyway). Alternatively, check return
> > code and don't use 'event_out' when something other than RTEMS_SUCCESSFUL
> > is returned.
> > 
> 
> Well, in my case *event_out is always zero before being used.

Then it's indeed a different story from what I've thought.

> I think, that the code path I'm talking about, includes a race condition
> when the rtems_event_receive() caller actually is dispatched after
> waiting. Then the return code is RTEMS_TIMEOUT and 'event_out' is changed.
> 
> At least I didn't see that the Wait.count variable of the waiting thread is
> set to zero by the _Event_Timeout() function, like it is done by the
> _Event_Surrender() function. This was added 2001 or so, as it fixes a bug
> when sending events from interrupt service handlers.
> 
> Please correct me, if I'm wrong.

Sorry, can neither correct you nor confirm you are right. Let's see if
somebody else knows better.

> 
> BTW, I can happily live with a return code of RTEMS_TIMEOUT and set 
> output events. I just wanted to make sure that this is the intended
> behavior.

I think you are right, it could be a bug... Finding a race in the kernel would
bother me as well...

-- 
Sergei.




More information about the users mailing list