[PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.
Gedare Bloom
gedare at rtems.org
Thu Aug 25 19:14:31 UTC 2016
On Thu, Aug 25, 2016 at 1:47 PM, Pavel Pisa <ppisa4lists at pikron.com> wrote:
> Hello Gedare,
>
> On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote:
>> On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa <ppisa4lists at pikron.com> wrote:
>> > Is there some defined function/way to check if RTEMS executive
>> > reached switch to multitasking mode?
>>
>> _System_state_Is_before_multitasking()
>
> Thanks, great that is what I have been looking for.
>
>> > This has impact to think about correct locking in functions
>> > which are required to be used during startup when there is
>> > no concurrent execution but mutexes support and memory initialization
>> > is not finished yet but the same functions can be used later
>> > when scheduler is running for further update of system state.
>> >
>> > More complete analysis and context in previous communication.
>>
>> I read prior discussion and had no problems, but Sebastian's concern
>> should be addressed whether other ARM targets are correct or not.
>
> His (correct) concern has been about SMP.
> But I think that need of locking has been eliminated by my previous commit.
> There is another reason against locking by IRQ disable or spinlock.
> If we consider update of pagetables at runtime where some real time tasks
> run then if scheduler is blocked but change in large part of address space
> then we can consider this as almost unbound latency source.
>
> So I vote for no locking at this level at all and mutex based locking
> (skipped if part of initialization and _System_state_Is_before_multitasking)
> at higher level when concurrent use need arises - for example allocation
> of virtual address space for mmap or something similar.
>
This seems reasonable to me. I expect to eventually add some (limited)
capabilities in this direction but I have not finished any (mental)
design.
> Best wishes,
>
> Pavel
>
>
More information about the devel
mailing list