Re: [lwip-devel] Require sys_arch_protect/unprotect to be correctly nested?

[Simon Goldschmidt]

Douglas wrote:
> Require sys_arch_protect/unprotect to be correctly nested?
> [..]
> So would a change to require sys_arch_protect/unprotect to have matching
> nesting be considered,

I'm not sure I fully understand your mail, so let me sum up how I see the 
PROTECT/UNPROTECT:

To be free in implementation, we *always* need the triple of 
DECL/PROTECT/UNPROTECT meaning:
- one can either store the old status in PROTECT and restore it in UNPROTECT
- *or* implement a nesting count, always lock, and unlock only for the last 
nesting (in that case, DECL is unused)
- a DECL must *not* be reused by a nested PROTECT to ensure UNPROTECT gets the 
correct level

In any case, every PROTECT needs a matching UNPROTECT!

> perhaps even cleaning these up by removing the *DECL_PROTECT macros and the 
> levels?

No, that would limit the use case to a nesting counter and prevent 
store/restore.

> A quick inspection suggests one non-nested use in alloc_socket, but that
> looks like a programming error and a patch will be submitted.

I haven't fully followed this discussion. Is this sorted out now?

> There is a use of these in socket.c:event_callback that looks
> problematic. There is a code comment:
> 
> "Don't call SYS_ARCH_UNPROTECT() before signaling the semaphore,
> [..]

I'm aware of this problem, but noone has suggested a fix for this, yet.
However, I'm tempted to remove the non-CORE_LOCKING code anyway, so this 
problem might eventually
just disappear...

Simon