[Top][All Lists]

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

Re: [lwip-users] Question about sys_arch.c *_free() vs. *_~set_invalid()

From: address@hidden
Subject: Re: [lwip-users] Question about sys_arch.c *_free() vs. *_~set_invalid()
Date: Fri, 12 Nov 2021 22:00:00 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0

Am 11.11.2021 um 22:38 schrieb Grant Edwards:
On 2021-11-11, Grant Edwards <grant.b.edwards@gmail.com> wrote:

[Sorry for all of the porting questions, but the sys_arch.c file I'm
working with just doesn't seem to make sense.]

I don't understand how *_free() and *_set_invalid() are supposed to

In the code I've inherited, when *_free() is called, my sys_arch.c
code places the referenced kernel object (semaphore or mailbox) back
into the free pool and it becomes available to be reallocated and
placed into use.

The lwIP documentation states:

    void sys_sem_set_invalid(sys_sem_t *sem)

    Invalidate a semaphore so that sys_sem_valid() returns 0.
    ATTENTION: This does NOT mean that the semaphore shall be
    deallocated: sys_sem_free() is always called before calling this

Apparently the sequence is


If invalid() is called for a particular semaphore _after_ that
semaphore has been free()ed, that semaphore may have already been
reallocated and might be in use by a different thread, socket,
whatever. Is the semaphore not supposed to be availble for
reallocation after being free()ed?

Are signal/wait calls on a mutex allowed between the free() call and
the set_invalid() call?

I've been looking at the freeRTOS port for edification, and that
hasn't really helped. In the freeRTOS port, the semaphore (for
example) becomes invalid when sys_sem_free() is called, so the call to
sys_sem_set_invalid() call will never have any effect [assuming the
documentation is correct and sys_sem_free() is always called before

In the freeRTOS port, the only time sys_sem_invalid() could have any
effect is if it were called before sys_sem_free(), and AFAICT that
would cause the underlying OS semaphore to be leaked.

Is an object's behavior supposed to change when
sys_object_set_invalid() is called?

Are there ports where an object is still valid after sys_*_free() is
called? After a semphore has been free()ed, what operations on an
already free()ed object would still be valid?

None. This is only a helper define to help defining sys_sem_free() to
something that might not make sys_sem_valid() return true.


reply via email to

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