[En-Nut-Discussion] ARP optimization deadlock

[Harald Kipp]

Dusan,

Thanks for your comments and your patience.

At 07:25 21.01.2005 +0100, you wrote:

>1) ARP entry exists so no ARP is sent from Nut/OS
>
>I expected that after 10 minutes ARP entry will be dismissed and 
>everything will continue normally.
>2) but thread NutArpExpire() is not created because this can be done only 
>from NutArpCacheUpdate() which itself is called from arpin.c:NutArpInput() 
>when incoming ARP is detected
>(this of course can happen after a long time)
>
>Solution for latter:    move thread running check & creation into 
>NutArpCacheNew()

I agree that this is a good solution.

And I agree that there is no simple solution for
the first problem. After further checking the code
I became more and more puzzled.

a) If NutArpCacheQuery() enters NutEventWait(&entry->ae_tq, 500),
then THREAD(NutArpExpire) may take over and remove the currently
requested entry.

b) ae_outdated is reset in NutArpCacheUpdate() only. Shouldn't
it be set to 0 on each usage?

c) In a very early version of Nut/OS updates were done in
interrupt context. There seem to exists several leftovers
in arpcache.c, like volatile declarations and critical
sections. Matthias Ringwald pointed this out too.

d) Actually I do not think that a separate thread for
deleting outdated entries is required at all. But I'd
refuse to implement such a global change right now.

Finally I agree with your opinion, that a flag will solve
the problem of not sending ARP requests. My suggestion is
to add a new flag to ae_flags, which indicates that the
entry is currently requested. This could also serve as a
lock to avoid removal by the background thread.

Harald