public inbox for
 help / color / mirror / Atom feed
From: "René Schipp von Branitz Nielsen" <>
To: <>
Subject: Cyg_Mutex::check_this() fails
Date: Wed, 13 Feb 2013 11:36:00 -0000	[thread overview]
Message-ID: <000901ce09de$3d3dc0d0$b7b94270$@cc> (raw)

...Sending this from my private mail account because the eCos mailserver
blocks mail containing confidentiality disclaimers, which I can't prevent
when sending from my work mail account... :( :(


Hello folks,

I have a condition variable, c, tied to a mutex, m, and used like this with
a FIFO, f:

void producer(void)
    copy_to_fifo(&f, some_data);

void consumer_thread(cyg_addrword_t data) {
    while (1) {
        while (fifo_empty(&f)) {

        // m is locked here.

        // Empty FIFO.
        while (!fifo_empty(&f)) {
            copy_from_fifo(&f, &some_data);

            // Do something with some_data


The following description refers to line numbers of rev. 1.15 of mutex.cxx.

When the system is under heavy interrupt load, threads may get scheduled in
and out more frequently than when not. Under these circumstances, I
sometimes get an assertion (cyg_assert_msg()) stemming from line 197 of
mutex.cxx, which is Cyg_Mutex::check_this(). Placing a breakpoint in this
function reveals that it happens when the consumer is about to wake up, that
is, in line 651, which is the second half of
Cyg_Condition_Variable::wait_inner( Cyg_Mutex *mx ).

A closer look at wait_inner() shows that when CYG_ASSERTCLASS( mx, "Corrupt
mutex") is invoked, the scheduler is not locked, which in turn means that
Cyg_Mutex::check_this() line 197 is tested non-atomically. Line 197
    if (( locked && owner == NULL ) return false;

So if the preemptive scheduler schedules the caller of cyg_cond_wait() out
in between the test of "locked" and "owner == NULL", and the mutex state
changes while scheduled out, we have a problem.

As I see it, CYG_ASSERTCLASS(some_obj, "some message") serves two purposes:
  1) check that some_obj is non-NULL and
  2) check that some_obj->check_this() returns TRUE.

IMO, only the first check needs to be made by wait_inner(), because line
#677 attempts to reacquire the mutex (mx->lock()), which itself performs the
check_this() check - and with the scheduler locked.

There are other places in mutex.cxx where CYG_ASSERTCLASS(Cyg_Mutex,
"message") is invoked without the scheduler locked, but I can't judge
whether these are OK or not.

Bottomline is that I suggest to change line #651 of mutex.cxx from
  CYG_ASSERTCLASS( mx, "Corrupt mutex"); to
  CYG_ASSERT(mx, "Invalid mutex pointer"); /* Or some other message */

Or is there anything fundamental, I have missed here?
Comments are appreciated.

Thanks in advance,
René Schipp von Branitz Nielsen
Vitesse Semiconductor Corporation

             reply	other threads:[~2013-02-13 11:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-13 11:36 René Schipp von Branitz Nielsen [this message]
2013-03-15 17:56 ` jamescmaki
2013-03-15 19:12   ` jamescmaki

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:

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

  git send-email \
    --in-reply-to='000901ce09de$3d3dc0d0$b7b94270$@cc' \ \ \

* 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).