public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Trenton D. Adams" <tadams@theone.dnsalias.com>
To: "'Nick Garnett'" <nickg@redhat.com>, <ecos-discuss@sources.redhat.com>
Subject: RE: [ECOS] cyg_cond_signal() without cyg_cond_wait ()
Date: Thu, 30 Aug 2001 08:04:00 -0000	[thread overview]
Message-ID: <000701c13165$081ef8f0$090110ac@TRENT> (raw)
In-Reply-To: <wwg66b5n97h.fsf@balti.cambridge.redhat.com>

I'm not using cyg_cond_signal() without locking the mutex.  I lock the
mutex before calling cyg_cond_signal(), but this doesn't make my other
thread that's using cyg_cond_wait() get back to the cyg_cond_wait() call
before cyg_cond_signal () is called!

Here's the example you gave me.

Producer thread:
  loop indefinitely
    acquire/wait for data
    lock mutex
    copy data to buffer
    update buffer pointers
    signal condition variable
    unlock mutex

Consumer thread:
  loop indefinitely
    lock mutex
    while buffer empty
      wait for condition variable
    copy data out of buffer
    update buffer pointers
    unlock mutex
    do something with data

Now, with the example above, the producer thread could signal the
condition variable while the consumer thread is at "do something with
data".  This would cause the condition variable to never be signaled.
However, I assume that's one of the reasons for the "while buffer
empty"?  After all, it won't even bother waiting for the condition
variable again because the buffer isn't empty.

However, what happens if the acquire thread happens to be twice as fast
at getting the data as the consumer thread is at "do something with
data"?  This would cause the buffer to be filled twice in which case the
old data is now gone.


-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Nick Garnett
Sent: Thursday, August 30, 2001 4:17 AM
To: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] cyg_cond_signal() without cyg_cond_wait ()
> Should I be locking the scheduler at the end of the loop until
> the next loop has started?  If I don't, it's theoretically possible
that
> a cyg_cond_signal () could occur before I get back to my cyg_cond_wait
> (), correct?
> 

If you are using cyg_cond_signal() without locking the mutex, then
that can happen. That is the price you pay for not using the mutex
"correctly". If you need proper synchronization between threads, they
must use the mutex. You should not be using the scheduler lock for
this. The state of the condition variable should not be treated as a
predicate. Its state can change unilaterally at any time. The true
predicate should be in data protected by the mutex, the condition
variable is just a signalling mechanism.


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

  reply	other threads:[~2001-08-30  8:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-29 13:32 Trenton D. Adams
2001-08-30  3:45 ` Nick Garnett
2001-08-30  8:04   ` Trenton D. Adams [this message]
2001-08-30  8:20     ` Nick Garnett
2001-08-30  8:56       ` Trenton D. Adams
2001-08-30  9:04         ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000701c13165$081ef8f0$090110ac@TRENT' \
    --to=tadams@theone.dnsalias.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=nickg@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).