lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII
Date: Wed, 08 Jan 2003 22:53:37 -0000

On Tuesday 16 October 2001 17:13, you wrote:
> > Time-outs are functions that are called after a specified amount of time.
> > The time-out functions must not be executed concurrently with the thread
> > which sets the time-out, not can they be called in an interrupt context.
> > There are a couple of ways to implement time-outs and I know of two
> > different approaches.
> >
> > In my lwIP ports (unix and RTXC), time-outs are processes in the
> > sys_mbox_fetch() and sys_sem_wait() functions, since threads can be
> > suspended in those functions. Internally, those functions wait either
> > until the semaphore/mailbox allows the thread to unblock, or until the
> > next time-out should happen. If the thread unblocks because a time-out is
> > scheduled to occur, the corresponding time-out function is called.
>
> If we add a new entry timeout (handled by most of OSes) in the
> sys_mbox_fetch() and sys_sem_wait()  functions and the corresponding
> handler(eg : tcp_timer_coarse ) in case of Timeout event, does it works ?
> How do we know the handler to call ?

Time-outs are thread specific. I.e., one thread cannot set a time-out in 
another thread. Therefore, no new timeout entries can be set while a thread 
is blocked. Time-outs can be set during execution of another time-out 
function - when the time-out function returns, the OS emulation layer should 
reschedule the time-outs before blocking the thread.

> > If the thread was unblocked because of a message arriving on the mailbox,
> > or because the semaphore was signalled, the time the thread was waiting
> > is subtracted from the time to the next time-out.
>
> Does it mean that if we wait for message arriving on the mailbox for 400 ms
> and the timeout is defined for 500ms, next time we wait that mailbox, the
> timeout will be of 100ms ?

Yes. This must all be implemented in the OS emulation layer (i.e., by you 
:-). In the current sources, this is done in the Unix OS emulation layer 
(src/arch/unix/sys.c) but not in the RTXC port (src/arch/rtxc/sys_arch.c). 

For the Unix port, I used a utlility module called dlist.c that implements a 
data structure known as a delta list. Look in the files src/arch/unix/dlist.c 
and src/arch/unix/include/arch/dlist.h.

> > The other approach taken to the implementation of time-outs is the one
> > taken by Hongsong Li in his lwIP port to uC/OS 1.09; instead of
> > processing time-outs within the sys_mbox_fetch() and sys_sem_wait()
> > functions, he has a separate thread that schedules the time-outs and at
> > the right time send a message to the mailbox in the lwIP main loop in
> > api/tcpip.c. When this message is received, the time-out function is
> > called within the TCP/IP thread.
>
> This means that in this thread, the time-out function can be called if the
> mailbox is not received on time ? If yes, which one tcp_timer_coarse or
> tcp_timer_fine ?

I'm not quite sure what you mean. Basically, he added another case statement 
to the switch in the function tcpip_thread() in the file src/api/tcpip.c. 
This case processed a time-out when a special message was posted to the 
mailbox from a scheduler thread.

> > For the 0.5 version of lwIP, the time-out scheduling (which is the most
> > complex part of the OS emulation layer) will be moved out of the sys_arch
> > file and into a generic implementation. The sys_sem_wait and
> > sys_mbox_fetch functions will be redesigned so that they take an extra
> > argument which is the maximum time to wait before unblocking and
> > returning to the caller. This will map nicely onto many OSes and will
> > make it easier to port lwIP to other platforms.
>
> I am not that familiar with TCP/IP but I tried to understand this logic ...
> It seems easier to start reprogramming those 2 functions with Timeout
> functionality included but I am not sure of the load of work, and the
> consequence on lwIP code  ?

It depends on the kind of support the underlying OS has (in this case, 
uC/OS). Look at the Unix OS emulation layer in src/arch/unix/sys.c, that 
should give you an idea of the amount of work needed. (The function called 
"cond_wait()" contains the time-out scheduling.) Much of the code in the Unix 
port can probably be reused.

Hope that clarifies things a bit.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam

[This message was sent through the lwip discussion list.]




reply via email to

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