lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] multi threading safe?


From: Leon Woestenberg
Subject: Re: [lwip-users] multi threading safe?
Date: Mon, 03 May 2004 23:31:40 +0200
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

Hello Eric,


Hi Leon, thanks for answering so quickly. I have another question pertaining
to multi-threaded safety.

Is it safe to:

1) Have all of my output code in 1 task, called task1 for example. And
then...

2) Have different tasks, each of which kick a different lwip timer. For
example, a task for the dhcp_coarse / fine timer, on for arp, and another
for the tcp timer. Even though these threads do not send or receive any data
and their sole purpose in life is to sleep for the timeout length, have the
os wake it up, call the timer routine and go back to sleep.

The general answer would be no, as it seems the task running some lwIP timer code could be pre-empted by second timer that makes another piece of lwIP code running (while the first was half-way adjusting datas
structures and whatsoever).

However, what interface to lwIP are you using, and does it exclude the
situation above?

Note that the lwIP core code is not thread-safe, and you can certainly NOT do the above safely from uCOS.

3) and most importantly... Handling the cs8900 ethernet isr's.
I wasn't sure how to go about this in a reasonable fashion, so
when a packet arrives, and causes an interrupt to occur, I used a global
netif struct declared in task1 for use in the isr handler since there was no
other way to gain reference to it since the isr is a vector and cant be
passed the netif structure when called.

This looks same, as the netif data structure is static memory and constant. Does the interrupt handler *need* the netif structure btw?

Basically, i enter the isr and then disable the interrupt pin, and post a
semaphore then exit the isr. This allows the OS to keep doing whatever its
doing.

Excellent.

I then have another task, task2, which wakes up due to the semaphore and
then services the cs8900 by reading the isq, and calling
cs8900if_input(netif) which goes to cs8900_input(netif) (gets the data from
the chip and returns a pbuf *), but that's where it ends.

Does your cs8900 driver, especially the cs8900if_input() function, match my driver in the CVS contrib module? (contrib/ports/c16x).

The driver must pass the packet to ARP, then pass it to netif->input().
Here is a snippet of code in cs8900.c/cs8900if_input():

  switch (htons(ethhdr->type)) {
  /* IP packet? */
  case ETHTYPE_IP:
    /* update ARP table, obtain first queued packet */
    q = etharp_ip_input(netif, p);
    /* skip Ethernet header */
    pbuf_header(p, -14);
    LWIP_DEBUGF(NETIF_DEBUG, ("cs8900_input: passing packet up to IP\n"));
    /* pass to network layer */
    netif->input(p, netif);
    break;


I work my way through ip_init and crash if the packet that came in was a
dhcp packet.

ip_init?

I wasn't sure what to do when I did the netif_add() so I configured the
interface with generic ip's to please the netif_add() - could this have been
done with ipaddressany?

Yes, a pointer to zero-initialized IP addresses is fine.

Point is, ip_init then crashes when it gets to if(netif==null) which I don't
really understand. Why would the netif every be null for a dhcp packet?

Please take more care in telling which code path the packet traverses and where you notice something going wrong. ip_init() is not used, maybe
you mean ip_input()

If I don't use dhcp, I can actually ping it for a bit before it crashes. The
response times are about 370-380ms. Though I would expect faster on a hcs12,
and have seen faster using code I wrote in assembly. <1ms.

Measure how long it takes from interrupt to driver. Once the driver runs, it should reply immediately (this is one non-blocking code path, see the IP to ICMP code).

This all sounds like a memory corruption or other kind of bug somewhere...

Regards,

Leon.




reply via email to

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