[Top][All Lists]
[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
Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf
- RE : [lwip-users] Timers & lwip tasks (a multithread question withLwIP),
Frédéric BERNON <=