RE: [ECOS] Condition Variables recap

["Trenton D. Adams" <tadams at theone dot dnsalias dot com>]

Actually, I'm looking at the code for Cyg_Condition_Variable in
mutex.cxx and according to it, it only dequeues ONE thread for
wakeup/signal, and not more than that.  So I _BELIEVE_ that Gary was
correct in what he said before.  Is this right?

    if( !queue.empty() )
    {
        // The queue is non-empty, so grab the next
        // thread from it and wake it up.

        Cyg_Thread *thread = queue.dequeue();	// _I_ SAY ONE THREAD
ONLY

        CYG_ASSERTCLASS( thread, "Bad thread pointer");
        
        thread->set_wake_reason( Cyg_Thread::DONE );
        
        thread->wake();

        CYG_INSTRUMENT_CONDVAR(WAKE, this, thread);
        
    }


-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[mailto:ecos-discuss-owner@sources.redhat.com] On Behalf Of Jonathan
Larmour
Sent: Tuesday, July 24, 2001 2:17 PM
To: Trenton D. Adams
Cc: 'eCos mailing list'
Subject: Re: [ECOS] Condition Variables recap


"Trenton D. Adams" wrote:
> 
> cyg_mutex_trylock () is not documented in my documentation.  I assume
> I'm not required to call that before the actual locking?

Curiously that is true. I'll make a note to fix that.

Gary Thomas wrote:
> The difference between cyg_cond_signal() and cyg_cond_broadcast() is
> that with the former at most one thread waiting on the condition
> variable will be awakened. 

You mean "at least", not "at most". cyg_cond_signal() may wake up more
than
one thread (which is the norm for CV implementations, not just eCos).
That's why you should always loop and retest the condition when doing a
cyg_cond_wait().

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
271062
Maybe this world is another planet's Hell -Aldous Huxley ||
Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions
http://www.redhat-techworld.com/