Thanks. I remember this now. We talked about this back in 2019!GregSent from
my Galaxy
Original message From: Xiang Xiao
Date: 4/23/23 10:09 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: Re:
sched_lock() should be completely removed On Sun, Apr 23, 2023 at 10:42 PM
On Sun, Apr 23, 2023 at 10:42 PM Gregory Nutt wrote:
>
> > Let's focus on the first two item:
> >
> > 1. Add sched_lock()'s ability to the enter_critical_section()
>
> Some will need to explain what this means. What is this?
If someone wakes up a high priority thread inside the critical
This is build from the repo and automatically published.
This particular file source is located here:
https://github.com/apache/nuttx/blob/master/Documentation/reference/user/03_task_control.rst
From the main documentation page you would find this under the API
Reference section and then
On 4/23/2023 10:16 AM, Brennan Ashton wrote:
On Sun, Apr 23, 2023, 3:57 PM Gregory Nutt wrote:
Possibly stupid idea: Maybe OStest needs
That point is that there was a lot of valuable documentation that has
been thrown in the shitcan and replaced with superficial how-to
documentation. There
On Sun, Apr 23, 2023, 3:57 PM Gregory Nutt wrote:
>
> > Possibly stupid idea: Maybe OStest needs
> That point is that there was a lot of valuable documentation that has
> been thrown in the shitcan and replaced with superficial how-to
> documentation. There is no longer technical documentation
Possibly stupid idea: Maybe OStest needs to become part of the OS and
not part of apps?
That is possible but leads to some issues some of which are only
cosmetic and some which are semantic.
* If we did that, it would not be an OS test. It would be an OS self
test of some kin.
* You
Let's focus on the first two item:
1. Add sched_lock()'s ability to the enter_critical_section()
Some will need to explain what this means. What is this? Why is it
needed? There is not sufficient information in this statement to
understand it.
On Sun, Apr 23, 2023 at 10:22 AM Gregory Nutt wrote:
> These are internal OS interfaces. In NuttX, sched_lock() is exported as
> a standard application interface. That, I think is wrong. An
> application should not require such an interface, there is no precedent
> in any standard for
hey there Yun, i am also strongly against removing working code that had
been here for a long time has been carefully designed gives granular
control etc.
Good words to like by:
* If it ain't broke don't fix it.
* Evolution , not revolution.
In the case of sched_lock(), it is a
Here is an example we found recently:
https://github.com/apache/nuttx/pull/9002/files
it's always wrong to use shced_lock as lock to protect the shared resource
like this.
Here is an issue which list all fixed done before:
https://github.com/apache/nuttx/issues/3600
Since it's very hard to
Hello, just a recommendation.
If something is prone to missuse by the users, don't remove it.
Rather:
* Document clearly it's quirks.
* Provide checks and assertions catching the missuse.
On Sun, Apr 23, 2023, 14:49 Sebastien Lorquet wrote:
> Hello,
>
> I have a similar feeling about this.
>
Hello,
I have a similar feeling about this.
Remember, if it isn't broken, dont fix it.
Sebastien
On 4/23/23 13:32, Tomek CEDRO wrote:
hey there Yun, i am also strongly against removing working code that had
been here for a long time has been carefully designed gives granular
control etc.
hey there Yun, i am also strongly against removing working code that had
been here for a long time has been carefully designed gives granular
control etc.
understanding of the code and possible misuse is up to developer.
maybe the problem needs better explanation and discussion which is always
Gregory Nutt 于2023年4月23日周日 04:24写道：
> I am not sure what this mean. But if you mean calling
> enter_critical_secion() in sched_lock(), then it is a very bad idea You
> should not do that. enter_critical_section() disables interrupts on all
> CPUs and this must never happen when disabling
On 4/20/2023 7:01 PM, jun hu wrote:
Thank you for your reply and providing additional information.
Based on your suggestion, I believe a reasonable solution about
sched_lock should be step by step.
1 Add sched_lock()'s ability to the enter_critical_section()
I am not sure what this mean.
and enter_critical_section are used simultaneously
3 Remove the sched_lock call from userspace
Finally, change the sched_lock's name.
BR!
Gregory Nutt 于2023年4月19日周三 21:42写道：
>
> > I think sched_lock() should be completely removed
> > most case we can rep
> I think sched_lock() should be completely removed
> most case we can replace sched_lock() with enter_critical_section(),
> at the sametime we add sched_lock()'s ability to the
enter_critical_section()
> we can replace sched_lock() with mutex ,sem or spinlock。
> directly r
bugs.
I think sched_lock() should be completely removed
1 most case we can replace sched_lock() with enter_critical_section(),
at the sametime we add sched_lock()'s ability to the enter_critical_section()
2 we can replace sched_lock() with mutex ,sem or spinlock。
3 directly removal
Any comments
18 matches
Mail list logo
