This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: from ISR to thread


Robin Farine <rfarine@dial.eunet.ch> writes:

> Please pardon me if I missed something here but I don't see how Nick's
> pseudo-code solves the problem Henning exposed.
> 
> 
> If the thread just finished to handle an event (after doSomething()
> but before cyg_cond_wait()) and a second interrupt occurs. Won't the
> thread then block on cyg_cond_wait() until the _next_ interrupt occurs
> and thus not handle the event associated with the missed interrupt?
> 

You're right, I was trying to make minimal changes to the original,
and got it wrong. The thread code needs to be structured more like this:

Threadcode:
{
  cyg_drv_mutex_lock(mx)
  data = null_data
  while(1)
  {

    if( data != null_data )
        doSomething(data)
    else
    {
        cyg_drv_dsr_lock()
        cyg_drv_isr_lock()
        data = rbuf.getdata()
        cyg_drv_isr_unlock()
        cyg_drv_cond_wait(cond)
        cyg_drv_dsr_unlock()
    }
  }
  cyg_drv_mutex_unlock(mx)

}

By using the DSR lock we ensure that the DSR cannot get called between
testing the ringbuffer and the cond_wait. Threads can wait with the
DSR lock claimed and if there is a pending DSR when the thread waits,
it will be woken up immediately and continue.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]