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 reproduce and fix this type of timing issue, we
need to review all places which call sched lock/unlock and fix the wrong
usage.

The suggestion:

   1. disable the userspace program call sched_lock/unlock
   2. but kernel can still call sched_lock/unlock

Since sched_lock/unlock is hard to use correctly if the caller doesn't
understand how the scheduler works. I agree with Greg that it's better
to forbid the usage sched_lock/unlock in userspace.
But, it's fine to keep it as before if you prefer to keep the freedom.
Let's focus on the first two item:

   1. Add sched_lock()'s ability to the enter_critical_section()
   2. Correct the incorrect usage of sched_lock step by step

Thanks

On Sun, Apr 23, 2023 at 7:54 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com>
wrote:

> 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 <sebast...@lorquet.fr>
> wrote:
>
> > 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.
> > >
> > > understanding of the code and possible misuse is up to developer.
> > >
> > > maybe the problem needs better explanation and discussion which is
> always
> > > good.
> > >
> > > but removing basic building blocks that work and already have strong
> > > dependencies is not how things are done in unix world. in fact this is
> > the
> > > kind of approach that destroys modern world (and the ict technologies).
> > it
> > > is impossible to build anything with no solid fundaments that
> constantly
> > > change. progress is about systematic development, step by step, on what
> > is
> > > already here, not by enforcing changes and removing things that work,
> > > evolution not revolution.
> > >
> > > have a good day :-)
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> >
>

Reply via email to