[En-Nut-Discussion] Possible race condition in DHCP and DHCPKick

[Ulrich Prinz]

Hi!

I will forward this to Daniel, a colleague of me who implements
STM32F107 EMAC actually. He did a lot testing/designing from bottom up
through the OSI model and fixed some other places too. He also
implemented my idea of phy.c.

Am 11.02.2012 17:20, schrieb Ole Reinhardt:
> Hi Henrik,
> 
> 
> 
> And another more complex situation:
> 
> 
>         else if (dhcpState == DHCPST_BOUND) {
>             retries = 0;
>             NutEventBroadcast(&dhcpDone);
>             if (dhcpConfig->dyn_renewalTime <= NutGetSeconds() -
> leaseTime) {
>                 dhcpState = DHCPST_RENEWING;
>             } else {
>                 /* Calculate the remaining lease time and take a nap. */
>                 napTime = dhcpConfig->dyn_renewalTime - (NutGetSeconds()
> - leaseTime);
>                 if (napTime > MAX_DHCP_NAPTIME) {
>                     napTime = MAX_DHCP_NAPTIME;
>                 }
>                 NutEventWait(&dhcpWake, napTime * 1000UL);
>             }
>         }
> 
> to 
> 
>         else if (dhcpState == DHCPST_BOUND) {
> 	    uint32_t now = NutGetSeconds();
>             retries = 0;
>             NutEventBroadcastAsync(&dhcpDone);
>             if (dhcpConfig->dyn_renewalTime <= now - leaseTime) {
>                 dhcpState = DHCPST_RENEWING;
>             } else {
>                 /* Calculate the remaining lease time and take a nap. */
>                 napTime = dhcpConfig->dyn_renewalTime - (now -
> leaseTime);
>                 if (napTime > MAX_DHCP_NAPTIME) {
>                     napTime = MAX_DHCP_NAPTIME;
>                 }
>                 NutEventWait(&dhcpWake, napTime * 1000UL);
>             }
>         }
> 
> The above is more complex as NutGetSeconds also could result in a
> context switch.

Isn't it more reliably to redesign dhcp into an active and a passive
part. The active part can work with post/wait and simply offers a
current_state variable like dhcpState.
If DHCP_BOUND or DHCP_TOUT is reached it goes to sleep and wait for a
restart-event.

The passive part only uses nutsleep(1000) and polls dhcpState for
spreading needed actions onto the stack and, if needed, wakes the active
thread above.
In that case only one thread is receiver and one is sender of an event.

If in that situation an event of the active part is missed by the
passive part, the next revolution of the passive part will get it.

With that no race conditions can occur anymore.

Ulrich