Possible bug in _Event_Surrender()

Phil Torre ptorre at zetron.com
Fri Mar 29 01:32:52 UTC 2002


This may be my own fault for allowing interrupts to nest, but I think
I've found a bug in the way threads get notified of received events.

(This pertains to RTEMS-4.5.0 on MPC860.)

The bug was noticed because we have a task that is waiting on events
from two different sources:  A timer service routine, and a hardware
interrupt.  The TSR has done its rtems_event_send(), and the event
that it sends has already been copied from api->pending_events to
the_thread->Wait.return_argument.  Interrupts are re-enabled and 
_Thread_Unblock() is about to be called.  Just then, our high-priority
hardware interrupt fires and does its own rtems_event_send().  The
event sent by the ISR is copied to the_thread->Wait.return_argument,
blowing away the event that was placed there by the TSR.

I patched c/src/exec/rtems/src/eventsurrender.c to fix it:

67c67
<         *(rtems_event_set *)the_thread->Wait.return_argument =
seized_events;
---
>         *(rtems_event_set *)the_thread->Wait.return_argument |=
seized_events;

If anyone thinks that's the wrong thing to do, please speak up!  :)

-Phil

-- 

=====================================================================
Phil Torre                               phone: 425-820-6363 x234
Design Engineer                          email: ptorre at zetron.com
Switching Systems Group                    fax: 425-820-7031
Zetron, Inc.                               web: http://www.zetron.com


  




More information about the users mailing list