On Thu, Aug 25, 2016 at 1:47 PM, Pavel Pisa <ppisa4li...@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 <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. > 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 > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel