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 <ppisa4li...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
