This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
AW: AW: AW: Blocking restricted in DSRs
- From: "Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>
- To: "Nick Garnett" <nickg at ecoscentric dot com>, <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 27 Jul 2004 12:43:58 +0200
- Subject: AW: AW: AW: [ECOS] Blocking restricted in DSRs
...
> > Ok, and what to do with the variables which are modified and which
> > should be protected by the mutex ? E.g. if I have a queue which is
> > filled by the DSR, and which is checked by the thread which waits
> > for the signal. Actually I have to ensure that the "take element out
> > of queue" by the thread is protected against the "put element into
> > queue" by the DSR. Do I have to use cyg_scheduler_lock() in the
> > thread to achieve this ?
>
> Yes. Take a look at the generic serial driver for an example of how to
> do this.
Ok, I had a look. The generic serial driver doesn't use cyg_sched_lock() (at least I didn't find it). The ipaq kbd driver uses it. It seems I simply have to replace the cyg_mutex_lock()/unlock() functions with cyg_scheduler_lock()/unlock() around the cyg_cond_wait() call.
while (1) //thread main loop
{
cyg_scheduler_lock();
while (queue.isEmpty())
cyg_cond_timed_wait(condition);
Item *i=queue.pop(); //access here or later after cyg_scheduler_unlock() ?
cyg_scheduler_unlock(); //do I have to call this here or directly before
//cyg_cond_timed_wait() ? but then the event could happen
//between cyg_scheduler_unlock() and cyg_cond_timed_wait() and
//the cyg_cond_timed_wait() would miss the signal ?
cyg_mutex_unlock(mutex); //this one should be locked here from looking at the code
//do something with i
}
But... I had a look at CygCond::wait_inner().
It calls CygSched::lock(), and later CygSched::unlock_reschedule(), and at the end mutex->unlock().
So if I call cyg_scheduler_lock() before cyg_cond_timed_wait(), the scheduler is locked twice but unlocked only once -> still locked. So there must be a point I missed.
Bye
Alex
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss