On 2021-11-11, Grant Edwards <grant.b.edwa...@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 > interact. > > 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 > function! > > 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. 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 sys_sem_set_invalid()]. 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? -- Grant _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
