lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] Problem with netconn_write()


From: Mountifield, Tony
Subject: [lwip-devel] Problem with netconn_write()
Date: Wed, 18 Aug 2004 17:05:43 +0100

Hi All,

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.

Comments?

Tony
-- 
Tony Mountifield
Contractor @ Tandberg TV
Strategic Park, ext 3390
Tel: 023 8057 3390


***********************************************************************************
This email, its content and any attachments is PRIVATE AND
CONFIDENTIAL to TANDBERG Television. If received in error please
notify the sender and destroy the original message and attachments.

www.tandbergtv.com
***********************************************************************************





reply via email to

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