[En-Nut-Discussion] Fwd: UartAvrFlush -- deadlock imminent??

[Harald Kipp]

>Delivered-To: web2p2 at p15095813.pureserver.info
>Date: Wed, 5 Nov 2003 14:03:55 -0800 (PST)
>From: JasonG
>Subject: UartAvrFlush -- deadlock imminent??
>To: en-nut-discussion at egnite.de
>
>
>This is from an older version of NutOS (2.5.91), but I think it's idea
>is still relevant.
>
>The function UartAvrFlush() might be called when someone wishes to
>purge their output buffer.  This results in the interrupts being
>disabled.  So below we're waiting on an event to post (which is done
>Async in the TxComplete function that is registered for the UARTs
>transmit complete handler), but interrupts are not enabled, so how can
>the TxComplete function ever be called?  It's the only function that
>posts an event to the queue that's being waited on.
>
>It seems like deadlock is imminent here unless the character has
>already been posted resulting in a queue that has already been signaled
>and the event will immediately run through.
>
>Please correct my train of thought here, because this obviously isn't
>the desired behavior.  Why do we enter the critical section before
>infinitely waiting on a character to arrive?  We would also normally
>want to let other tasks operate while this thread is suspended waiting
>for that character(s) to be sent out.
>
>Thanks!
>
>
>int UartAvrFlush(NUTDEVICE *dev)
>{
>     IFSTREAM *ifs = dev->dev_icb;
>     UARTDCB *dcb = dev->dev_dcb;
>
>     /*
>      * Start any pending output.
>      */
>     if(UartAvrOutput(dev))
>         return -1;
>
>     /*
>      * Wait until output buffer empty.
>      */
>     NutEnterCritical();
>     if(ifs->if_tx_idx != ifs->if_wr_idx)
>         NutEventWait(&dcb->dcb_tx_rdy, 0);
>     NutExitCritical();
>
>     return 0;
>}
>
>static inline void NutEnterCritical(void)
>{
>     asm volatile(
>         "in  __tmp_reg__, __SREG__" "\n\t"
>         "push __tmp_reg__"          "\n\t"
>         "cli"                       "\n\t"
>     );
>}
>
>
>=====
>JasonG
>jas_g at yahoo.com