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

[Philipp Burch]

On 19.11.2014 17:02, Harald Kipp wrote:
> On 19.11.2014 16:49, Harald Kipp wrote:
>> On 19.11.2014 16:25, Philipp Burch wrote:
>>> On 19.11.2014 14:54, Harald Kipp wrote:
>>>> While Nut/OS is cooperative, mutual exclusion can be done with much less
>>>> effort: 
>>> I'm aware of the cooperative nature of Nut/OS and the benefits of that,
>>> but I think that this solution won't be ideal here. The problem only
>>> arises if two threads try to initialize the TCP state machine "at the
>>> same time". When the first thread enters the function, it will set the
>>> flag to 1 indicating that the initialization is complete, which is
>>> actually a lie. 
>>
>> 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 ;)
> 
> If I got it right, the problem was, that the state machine may be
> started twice. As far as I can see, it doesn't generally harm, if the
> state machine isn't running when NutTcpInitStateMachine() returns.
> 
> Except that NutTcpStateMachine() responds with TCP_REJECT to an early
> incoming request. But that could be avoided by using the lock variable
> from my example instead of the tcpThread pointer to check, whether the
> NutTcpSm thread is about to start.
>