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

[Frédéric BERNON]

>>Frédéric BERNON wrote:
>> 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?
>
>It's theoretically possible I guess: it would imply the tcpip thread didn't 
>have a chance to run until the ARP timeout triggered. Improbable but 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)...
>
>It seems that would be the best course then. I'm not sure if there's any 
>appropriate place to document this so people are aware of the issue.


Ok with you, but just something, when you say : "it would imply the tcpip 
thread didn't have a chance to run until the ARP timeout triggered". The arp 
timer "have" to call etharp_tmr at a 10 second regular interval (like it's 
written in rawapi.txt, even if ARP_TMR_INTERVAL is defined to 5000 in 
etharp.h), and tcpip_thread never stop, and also call etharp (for 
etharp_output). More, the task receiving packets call etharp_ip_input if 
ETHARP_TRUST_IP_MAC is defined (and it's always call etharp_arp_input for ARP 
packets - I think that most of the code in "ethernetif_input" would have to be 
moved in the "netif->input").

So, ARP table can be access in the same time by arp timer task, tcpip_thread, 
and network device driver receive task (in the worst case). I suppose that why 
in CHANGELOG file, there is always written :

" * TODO: the ARP layer is not protected against concurrent access. If
    you run from a multitasking OS, serialize access to ARP (called from
    your network device driver and from a timeout thread.)"

So, in a multithread environment with upper layers, I think it's a good to 
define ETHARP_TRUST_IP_MAC to 0, and to initialize the arp_timer in the 
tcpip_thread context (which can handle "timeouts") to reduce this kind of 
problem, like this :

static void tcpip_init_done( void *arg)
{ sys_timeout( ARP_TMR_INTERVAL, arp_timer, NULL);
  sys_sem_signal(*((sys_sem_t *)(arg)));  
}

I'm not sure about real problems cause by these concurrent access, but it's a 
good thing  to know. In a general way, there isn't lot of information about 
using LwIP in a multithread system. To raw api, we get a rawapi.txt file, so, 
why not a sequentialapi.txt file to explain sockets and netconn layers? I only 
found these informations :

1/ http://www.sics.se/~adam/lwip/os.html 

2/ In rawapi.txt :

"lwIP provides two Application Program's Interfaces (APIs) for programs
to use for communication with the TCP/IP code:
* low-level "core" / "callback" or "raw" API.
* higher-level "sequential" API.

The sequential API provides a way for ordinary, sequential, programs
to use the lwIP stack. It is quite similar to the BSD socket API. The
model of execution is based on the blocking open-read-write-close
paradigm. Since the TCP/IP stack is event based by nature, the TCP/IP
code and the application program must reside in different execution
contexts (threads)."

3/ "12.2 Implementation of the API" part of "Design and Implementation of the 
lwIP TCP/IP Stack" by Adam Dunkels.

4/ And a note from Kieran Mansley in the thread "lwip_sendto: possible to 
corruptremoteaddr/port connection state" started by Thomas Taranowski: 

"You're right about the assumption that there's only one calling thread per 
netconn.  That is a deliberate decision to keep things simple, and in most 
cases will be true.  If a resource of any sort is used from two or more 
threads, it is usually up to the threads to synchronize access to it, and in 
this respect a netconn is no different.

It does differ to what people might expect though, so perhaps we need to 
document this aspect of the API better.

An alternative would be to overhaul the sockets API as you suggest and make it 
thread safe.  I think that is unlikely to happen, but leave the option open for 
others if they wish to do this."

I hope these informations will help Thomas Taranowski if he wants to post any 
documentations...

Last, I don't know if it's important to change, but in the unix ports, in the 
sample simhost.c + tapif.c, the arp_timer is initialized in tapif_init, in the 
main_thread context. Perhaps initialize it in tcpip_init_done (to provide a 
good sample)??
  
====================================
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é : mardi 27 février 2007 16:18
À : Mailing list for lwIP users
Objet : Re: RE : [lwip-users] Timers & lwip tasks (a multithread 
questionwithLwIP)


Frédéric BERNON wrote:
> 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?

It's theoretically possible I guess: it would imply the tcpip thread didn't 
have a chance to run until the ARP timeout triggered. Improbable but 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)...

It seems that would be the best course then. I'm not sure if there's any 
appropriate place to document this so people are aware of the issue.

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