sched: nxtask_start should call entry point directly for kernel thread

[xiaoxiang781216]

Summary

since nxtask_startup will initialize c++ global variables which shouldn't be done inside the kernel thread.

Impact

C++ global variables may initialize twice when SMP is enabled because cxx_initialize don't have any sync code. But we don't need add mutex/spinlock code to cxx_initialize, because we should avoid the kernel thread call cxx_initialize in the first place. Once we ensure that cxx_initialize get called only inside the user task entry point, the sync isn't a problem anymore because NuttX kernel always create one and only one user task(init).

Testing

[jerpelea]

I don't think that this change is going into the right direction since we will see more and more SMP capable HW

[xiaoxiang781216]

I don't think that this change is going into the right direction since we will see more and more SMP capable HW

@jerpelea could you give more info? This patch fix the problem we found in SMP configuration.

[xiaoxiang781216]

@jerpelea could you review again?

[masayuki2009]

@xiaoxiang781216

As long as I checked the latest upstream, I think the issue does not relate to SMP.
Actually the issue happens with lm3s6965-ek:discover configuration.

Also, I noticed that this PR only resolves the issue for kernel thread as titled.
However, for example, lm3s6965-ek:discover creates 'Telnet daemon' which
will call cxx_initialize() in nxtask_startup().

[xiaoxiang781216]

@xiaoxiang781216

As long as I checked the latest upstream, I think the issue does not relate to SMP.

Yes, it isn't SMP specific. SMP just expose the problem:
Two CPUs idle thread call nxtask_startup->cxx_initialize at the same time which make all global constructors are executed twice.
But the real issue is that we shouldn't initialize C++ global variables inside kernel space at all, because all kernel threads(include idle thread) shouldn't use any C++ element at all).

The good side effect with this fix is that the synchronization issue also get resolved too, because kernel always create one and only one user task(init) and cxx_initialize get called before init's main has the chance to create more tasks concurrently.

Actually the issue happens with lm3s6965-ek:discover configuration.

Also, I noticed that this PR only resolves the issue for kernel thread as titled.
However, for example, lm3s6965-ek:discover creates 'Telnet daemon' which
will call cxx_initialize() in nxtask_startup().

Yes, it is the expected behaviour, please see PR: #1341 and apache/nuttx-apps#316.
The motivation is centralize the c++ initialization to common place. Of course, all old code which call cxx_initialize manually should be removed to avoid the double initialization issue.

[masayuki2009]

@xiaoxiang781216
Thaks for your detailed explanation.

@jerpelea
I think it looks good to me but do you have any other comments.

[jerpelea]

LGTM