This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: cyg_cond_signal() without cyg_cond_wait ()
- To: "Trenton D. Adams" <tadams at theone dot dnsalias dot com>
- Subject: Re: [ECOS] cyg_cond_signal() without cyg_cond_wait ()
- From: Nick Garnett <nickg at redhat dot com>
- Date: 30 Aug 2001 17:04:34 +0100
- Cc: <ecos-discuss at sources dot redhat dot com>
- References: <000801c1316c$4503caf0$090110ac@TRENT>
"Trenton D. Adams" <tadams@theone.dnsalias.com> writes:
> Ok, that makes sense. I thought you might have to use another condition
> variable, but I wasn't sure if that was good practice.
Having several conditions within a single critical region is normal
practice.
> However, it
> WOULD be bad practice to lock the scheduler until I'm done doing
> something with the data!
Exactly.
>
> My other solution of locking the mutex until the start of the next loop
> would work too though right?
Probably, but it is not something I want to seen to encourage. Mutexes
should be kept locked for the minimum period possible.
--
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK