lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Are sys_arch_protect/unprotect required to nest?


From: Grant Edwards
Subject: Re: [lwip-users] Are sys_arch_protect/unprotect required to nest?
Date: Mon, 15 Nov 2021 16:33:27 -0000 (UTC)
User-agent: slrn/1.0.3 (Linux)

On 2021-11-15, Ajay Bhargav via lwip-users <lwip-users@nongnu.org> wrote:

> protect/unprotect is totally implementation dependent with only
> intention of providing exclusive access to network related operation
> to be performed without any context switching. You can do this by
> using a mutext in simplest way

Are you assuming that mutex lock/unlock nest? Not all OSes provide
nesting/recursive mutexes.

> but you have to make sure ISR do not do any operation either when
> system is locked,

Yes, I understand that.

> this can be implemented with a complex implementation but still
> possible. I have dealt with such system in past where critical
> section APIs were not possible to use and only possible option was
> to use a mutex.

> lev may or may not be used which again depends on your
> implementation.

If it is used, is it supposed to override the nesting? The
documentation states that sys_arch_unprotect(lev) sets the protection
level to `lev`. What is the correct behavor if that `lev` conflicts
with the call nesting level?

> For your RTOS where nested critical section is not possible,

I didn't say it wasn't possible, I said it wasn't provided. I've now
added a nesting version of of the RTOS calls to enter/exit critical
section. I just needed to know if nesting was required (it's not
stated in the documentation).

> Disabling of context switch is the only requirement of lwip when it
> comes to protect/unprotect.

I thought the nesting behavior was also a requirement?

> Implementation is upon the programmer depending on system.

Right. I have no problem implementing the requirements. I'm just
trying to figure out what the requirements actually _are_.

--
Grant




reply via email to

[Prev in Thread] Current Thread [Next in Thread]