lwip-users
[Top][All Lists]
Advanced

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

RE : [lwip-users] Timers & lwip tasks (a multithread question withLwIP)


From: Frédéric BERNON
Subject: RE : [lwip-users] Timers & lwip tasks (a multithread question withLwIP)
Date: Mon, 26 Feb 2007 22:08:14 +0100

But, if the main() task handle the ARP Timer (and read/write the arp table), 
and if tcpip_thread also read/write in arp table, is the corruption possible?

Perhaps, as you suggest, it will be better to put arp_timer initialization 
directly in the callback (to be in another file than the tcpip.c, but in the 
same thread than the tcpip_thread)...
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Jonathan Larmour
Envoyé : lundi 26 février 2007 20:37
À : Mailing list for lwIP users
Objet : Re: [lwip-users] Timers & lwip tasks (a multithread question withLwIP)


Frédéric BERNON wrote:
> Lwip needs some "timers" for ARP (etharp_tmr), DHCP (dhcp_fine_tmr & 
> dhcp_coarse_tmr), SNMP (snmp_timer), etc...
> 
> My question is mainly about arp timer, because the table handled in 
> etharp.c is in read/write access. In several ports, I see that 
> arp_timer is initialized by the main() task during the netif_add(...) 
> call (with the "init" function). But when we use the tcpip_init, which 
> create its own task, isn't it possible that the arp list was "corrupt" 
> due to a multithreaded access?

Not every port can be considered accurate - in fact I doubt any of them are 
in one sense :-).

I don't know which ports you've looked at, but the eCos and UNIX ports (at 
least) wait until the tcpip task is definitely running,  by using the 
callback passed as the first argument to tcpip_init. That way the ARP timer 
is definitely set up afterwards, one way or the other. This could be done 
either directly in the callback at that point, or by some subsequent part 
of the initialisation function, which would have gone to sleep after the 
call to tcpip_init until woken up by that callback.

> And if it's right, isn't it a better place to initialize these timers 
> directly in tcpip_thread(...), like the ip_timer for IP_REASSEMBLY, to 
> be sure that only one task will use lwip core in the same time?

The tcpip_thread code is generic, and isn't aware of whether or when the 
arp timer should be started.

Jifl
-- 
eCosCentric Ltd  http://www.eCosCentric.com/  The eCos and RedBoot experts
   **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
   **  April 3-5 2007, Booth 1922, San Jose McEnery Convention Center  **
Company legal info, address and number:   http://www.ecoscentric.com/legal
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Attachment: Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf


reply via email to

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