Waiting for multiple events
Till Straumann
strauman at slac.stanford.edu
Tue Nov 29 18:12:12 UTC 2011
Note the following (IIRC)
1) signaling to a posix condvar on which no thread is blocking has no
effect. Unlike an event which is left 'pending' when sent to a task
that is not yet waiting for it.
2) a posix condvar is accompanied by a mutex which must be locked
by the receiver and should be locked by the sender - which is
prohibited in an ISR. However, if you only use the condvar for
synchronization (and do not care about/use/change the value
of the variable itself) then is should be safe to signal w/o locking
the mutex. But property 1) may tempt you to use a variable
(or the condvar itself) to 'remember' pending interrupts.
In this case you must be extremely careful in order to avoid
race conditions since you must not lock the mutex in the ISR.
-- T.
On 11/29/2011 09:21 AM, Joel Sherrill wrote:
> On 11/29/2011 11:11 AM, Sergei Organov wrote:
>> Peter Dufault<dufault at hda.com> writes:
>>
>>> On Nov 29, 2011, at 10:32 , Mogens Dybæk Christensen wrote:
>>>
>>>> That will require manual modification of approx. 25 source files, so
>>>> it is possible. The original idea was just to replace the OS
>>>> wrapper, but the footprint seems too different.
>>>>
>>> Can you describe the interface you want to wrap? I googled RTXC but
>>> the "semaphore list" interface wasn't clear. Maybe someone can then
>>> suggest a POSIXY or RTEMS way of wrapping it.
>> Well, POSIXy way of waiting for arbitrary complex condition(s) is
>> 'condvar', but POSIX itself has no notion of interrupts, so only if
>> RTEMS provides corresponding extension(s) (signaling condvar from ISR)
>> will it be useful in the context of OP question.
> Every core thread operating that unblocks is supposed to be safe
> from an ISR.
>
> FWIW I like sending events or messages from interrupts personally.
>> -- Sergei.
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>
More information about the users
mailing list