[En-Nut-Discussion] Another set of eyes

[Ralph Mason]

Well I tracked it down.

Basically NutPostAsync doesn't have Enter / Exit Critical in it.

So it can be in there and be called reentrantly by an Interrupt handler
(timer interrupt) causing the timer interrupt to adjust the Running Thread
Que while the running thread is also doing it.

Didn't show up on the PC because the PC is so much faster.

Anyway my fix (if you couldn't guess)

int NutEventPostAsync(HANDLE volatile *qhp)
{
    NUTTHREADINFO *td;
    int rc = 0;

    NutEnterCritical();

    if (*qhp != SIGNALED) {
        if ((td = *qhp) != 0) {
            NutThreadRemoveQueue(td, (NUTTHREADINFO * volatile *) qhp);

            /*
             * Stop any running timeout timer.
             */
            if (td->td_timer)
                NutTimerStopAsync(td->td_timer);
            NutThreadResumeAsync(td);
            rc++;
        } else
            *qhp = SIGNALED;
    }

    NutExitCritical();

    return rc;
}

Ralph



> -----Original Message-----
> From: en-nut-discussion-admin at egnite.de
> [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Ralph Mason
> Sent: Monday, 21 July 2003 8:38
> To: en-Nut-Discussion
> Subject: [En-Nut-Discussion] Another set of eyes
>
>
> I am looking for a seconds set of eyes on some code. And to make a
> contribution.
>
> I have written a message que for NutOS to allow a thread to wait
> on multiple
> objects and make IPC easier.
>
> I have been over the code again and again, it appears to work perfectly on
> the PC but when it runs on the hardware I get random stopping of threads
> (not involved with the que) they show as ready to run and they
> have the run
> que as the queue. eg
>
> 0000312F cli        64 RUN 00000C6B 00000000 0000E709 4294948314 CR 312F
> 1301
> 0000310C Leds       20 RDY 00000C6B 00000000 000030F1   357 OK 312F 1301
> 00002F69 Power      64 SLP 00000000 00006DCB 00002F4E   357 OK
> 00001301 idle      254 RDY 00000C6B 00000000 000012E9   360 OK 312F 1301
>
> Ignore the thread that says it's corrupted (it's running in paged space so
> without changing the thread dump function it cant access its
> stack.  It *is*
> fine.
>
> But the interesting thing is here the Leds thread has stopped running.  It
> shows as ready and *thinks* it's in the run queue, but doesn't show there.
>
> The code I am using with the Message Que has 2 threads, one lower priority
> that reads from a com port to a buffer on it's stack, one with a higher
> priority that reads the message que and processes the data from the other
> thread.  Because the higher priority thread will never yield the lower
> priority thread can use a single buffer.
>
> Everything else seems totally fine, if I don't use the message que then it
> works fine.
>
> Any help or thoughts are very welcomed.
>
> Thanks
> Ralph
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003