lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] upgrading to 1.4.0


From: FreeRTOS Info
Subject: Re: [lwip-users] upgrading to 1.4.0
Date: Thu, 23 Jun 2011 13:54:50 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10

On 23/06/2011 12:27, Martin Velek wrote:
> Hi,
> I am doing an upgrade of LWIP from 1.3.2 to 1.4.0(#define NO_SYS 0,
> the OS supports mutexes) . Please, could you help me to confirm the
> following steps?
> 
> 1) Remove all stuff around timers, these are now completely handled inside 
> LWIP.
> 
> 2) Change function prototypes and implementation around semaphores, 
> mboxes,etc.
> 
> 3) Add new functions to support mutexes and typedef __type__ sys_mutex_t
> 
> 4) Add new functions to determine if sem/mbox/mutex is valid or to invalide 
> it.
> Here I would like to ask, what is good *_invalide() for. If this
> functions is called, should I also free the sem/msg/mutex? I could
> understand the *_invalide() is called if and only if during an
> initialization process to set variables into a known state or after
> freeing by *_free().
> 
> E.g. with a FreeRTOS, the semaphore is of a type void * and NULL value
> is (void *)0. However, if the semaphore is created and then
> invalidated, from the function name I would propose that the function
> should set the semaphore to the NULL because there is a function
> sys_sem_free() to free the semaphore. There will be a memory leak if I
> set the semaphore to the NULL in the *_invalide() function. Or what is
> worse, the sys_sem_free() will fail with a NULL semaphore.

Just to comment on the FreeRTOS part...

In FreeRTOS a semaphore is actually of type xSemaphoreHandle.  Inside
the function that implements the semaphore this is defined to be a
pointer to the semaphore structure.  Outside of that function, for
reasons of standard data hiding, it is defined as (as you say) a void *.
 That way, the user cannot access its internals directly.

Semaphores are built onto of the queue primitive (to use the event
management of the queue while keeping the code size very small).  You
can therefore delete a mutex (or any other type of semaphore) by calling
vQueueDelete( <semaphore handle> ).  Depending on the compiler, you may
need to case <semaphore handle) to a xQueueHandle type - but that should
not be necessary as queue handles also appear as void* outside of the
file that implements the queue API.

Deleting a queue will cause the memory allocated to store the queue
structure and the queue storage area to be freed (the queue storage area
for a semaphore is zero bytes long anyway).  *However* you should not
delete a mutex that is being held by a task, or delete a mutex that has
tasks waiting for it to be released.

Don't know if that helps answer that part.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.






> 
> 
> Did I miss something?
> 
> Thank you
> Martin
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 



reply via email to

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