[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,
NUT_THREAD_TCPSMSTACK * NUT_THREAD_STACK_MULT + NUT_THREAD_STACK_ADD);
if (tcpThread == NULL) {
rc = -1;
}
}
NutEventPost(&tcp_initialised);
return rc;
}
It's the same as with a mutex, but does not use the mutex imlementation.
Bye,
Ole
--
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de
More information about the En-Nut-Discussion
mailing list