[En-Nut-Discussion] Race condition and stack overflow in tcpsm.c

[Philipp Burch]

Hi everyone!

On 20.11.2014 23:43, Ole Reinhardt wrote:
> Hi Philipp, Hi Harald,
> 
>>>> Oops! Yes, you are perfectly right. My solution won't work.
>>>
>>> Or does it? :-)
>>
>> Well, it might, as I wrote earlier. If the thread is not actually
>> executing something, this should not be a problem. But it could be a
>> problem if some other code tries to access the thread variable before it
>> is being assigned a value. But as stated, it is possible that this
>> variable isn't used anywhere except in NutTcpInitStateMachine(). As long
>> as this is also true in the future, it should work ;)
> 
> Well, but what about the following solution? This should fix the problem
> with standard Nut/OS functions instead of using application candy and
> does not allow other threads to use the thread variables...
> 
> HANDLE tcp_initialised = SIGNALED;
> 
> int NutTcpInitStateMachine(void)
> {
>     int rc = 0;
>     NutEventWait(&tcp_initialised, NUT_WAIT_INFINITE);
>     if (tcpThread == NULL) {
>         tcpThread = NutThreadCreate("tcpsm", NutTcpSm, NULL,
> NUT_THREAD_TCPSMSTACK * NUT_THREAD_STACK_MULT + NUT_THREAD_STACK_ADD);
>         if (tcpThread == NULL) {
>             rc = -1;
>         }
>     }
>     NutEventPost(&tcp_initialised);
>     return rc;
> }

This solution is now committed as r5911 in devnut_tiva. r5910 reverts
the mutex implementation in r5883, so the last revision is a clean patch
to trunk.

Cheers,
Philipp