[PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

Chris Johns chrisj at rtems.org
Fri Aug 26 00:22:19 UTC 2016


Hi Pavel,

I am sorry about the delay. I have been on other things and then I was 
out with a pesky flue virus for the past week.

On 26/08/2016 03:47, Pavel Pisa 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.
>

Great. I was hoping you would provide a clear decision. I agree. I will 
remove the interrupt mask and push the change.

Thanks for posts and the detail. It is really valuable.

Chris


More information about the devel mailing list