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

Ole Reinhardt ole.reinhardt at embedded-it.de
Thu Nov 20 23:43:18 CET 2014

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,
        if (tcpThread == NULL) {
            rc = -1;
    return rc;

It's the same as with a mutex, but does not use the mutex imlementation.



kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen

More information about the En-Nut-Discussion mailing list