I've just run into a problem with netconn_write() and its interaction with
sent_tcp().
Having sped up my execution by enabling the CPU cache (this is new hardware), I
started finding the underlying OS would occasionally hit a fatal error due to
trying to signal a deleted semaphore. This was always in sent_tcp(), in the
following code:
if (conn != NULL && conn->sem != SYS_SEM_NULL) {
sys_sem_signal(conn->sem);
}
The thread was being pre-empted after testing conn->sem, so that by the time my
implementation of sys_sem_signal() called the OS, another thread had already come
along and deleted the semaphore.
I deduced that the culprit was netconn_write() in api_msg.c: it creates a
semaphore on entry, if it doesn't already exist, whic is fair enough. However,
it deletes it again just before it exits. So for every write a semaphore is
getting created and then deleted. Surely it would be better to leave the
semaphore in existence, and free it in netconn_close().
In any case, assuming sys_sem_signal() and sys_sem_free() can't block, there
should perhaps be some exclusion to make sure that a test of conn->sem and its
subsequent use are indivisble, for semaphores that can be dynamically deleted.