On 22.05.2012 20:01, Martin Laabs wrote:
> unfortunately I couldn't find the answer in the documentation. If the
> scheduler runs a DSR. Can this DSR become interrupted by an other thread
> or another DSR? (Of cause an ISR can interrupt it)
No. The scheduler lock is claimed while running the DSR
and as far as I know the DSRs are serialized. I can't
comment on multiprocessor cases.
> The background is that I wanna share data between a thread an a DSR and
> want to know whether I have to call cyg_(un)lock_scheduler when changing
> the data.
You most probably want to. A thread cannot preempt a DSR, but a DSR
will preempt a thread. So the structures used by both should
be protected.
> And another question about that - how are memory barriers implemented in
> eCos? (Are they implemented at all?)
Search for the HAL_REORDER_BARRIER in your HAL.
> Background: I have - for example - a status bit field that is copied to
> a (ISR/DSR) shared variable in the ISR. Now - if the compiler decides to
> put this variable into a register (in the ISR function) the DSR will get
> the wrong data. I could of cause declare the variable as volatile but
> this might be a performance issue in other cases where more data is
> affected.
A memory barrier and volatile are different beasts. A barrier
only prevents reordering of the memory accesses; it does nothing
with decisions of the compiler what to put in a register or
what optimization it can perform. At least not generally -
maybe gcc gives more guarantees. But it does this even regarding
visibility from other processor cores.
On the other side volatile guarantees that all memory accesses
actually take place and prevents reordering of the volatile
accesses. It does not preserve any order with relation to
non-volatile ones and on a multiprocessor system the order
observed from another processor might be different.
Regarding your case: an eCos driver should not allow the ISR
from the same source to be called before the DSR is complete
(you normally mask and ack the interrupt source in the ISR
and unmask at the end of its DSR).
For the thread/DSR synchronisation use cyg_drv_dsr_lock/unlock
which on systems with scheduler map to cyg_scheduler_lock/unlock.
This guarantees that no DSR will run while a thread is in this
section.
You for sure don't need the barrier here - the lock/unlock will
take care of this (if not, it is a bug).
Strictly said you need volatile here, because if the compiler
provably finds out that the lock/unlock calls do not touch
the variable in question, it is free to cache it in the register
across that call. However, with the function being in another
compilation unit this would be only possible with some
link-time optimization and it would need adressing at much
broader level anyway.
Regards
--
Stano
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
