lwip-users
[Top][All Lists]
Advanced

[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: Grant Edwards
Subject: Re: [lwip-users] Question about sys_arch.c *_free() vs. *_~set_invalid()
Date: Thu, 11 Nov 2021 23:17:11 -0000 (UTC)
User-agent: slrn/1.0.3 (Linux)

On 2021-11-11, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> 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.


> Apparently the sequence is
>
>   new(sem)
>   free(sem)
>   invalid(sem)
>
> 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.

It appears that the original authors of my sys_arch.c file were so far
off the rails they couldn't even see the telegraph poles any more. I
think that this confusion was caused by ambiguous language in the
documentation that fails to clearly differentiate between the instance
of the C types sys_sem_t and the underlying OS kernel object.

The authors of my code understood the documentation to mean that the
"valid" state was a property of the underlying kernel object. After
calling free(), that kernel object and _sys_*_t struct both remain
valid, and the kernel object is returned to the free pool where it can
then be allocated by a call to new().

That new() call could happen before the "previous owner" called
set_invalid(). In that case, the underlying kernel object would be
then be marked as invalid and would stop working for the new owner.

That's obviously not correct. The "valid" state is not a property of
the underlying kernel object.  The "valid" state is a property of the
sys_sem_t and sys_mbox_t struct itself, not of the underlying kernel
object. This obviously wasn't stated clearly enough for the previous
authors, and it took me several days to figure out the difference
between a "semaphore" and a "semaphore". ;)

--
Grant




reply via email to

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