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