public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: Grant Edwards <grant.b.edwards@gmail.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS]  Re: Question about cyg_flag_timed_wait()
Date: Sat, 02 Jan 2010 20:14:00 -0000	[thread overview]
Message-ID: <pnd41sz2ln.fsf@delenn.bartv.net> (raw)
In-Reply-To: <hgtert$l5g$1@ger.gmane.org> (message from Grant Edwards on Wed, 	23 Dec 2009 16:01:01 +0000 (UTC))

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

    Grant> On 2009-11-02, Grant Edwards <grant.b.edwards@gmail.com>
    Grant> wrote:
    >> A colleague working on an eCos app is reporting that
    >> cyg_flag_timed_wait() doesn't resume immediately when the flag
    >> is set. He says it won't resume until the next system tick
    >> (which results in a delay of up to 10ms). So instead he uses
    >> cyg_thread_delay() and cyg_thread_release() and claims that the
    >> released thread starts immediately in that case.

    Grant> This "problem" seems to have come up again. I've looked at
    Grant> the event flag code, and I can't see how there could be a
    Grant> delay when waking a thread using cyg_thread_setbits() and
    Grant> not when waking a thread using cyg_thread_release().

    Grant> Both cases just end up calling the target thread's wake()
    Grant> method. The only difference is that cyg_thread_release()
    Grant> calls wake() unconditionally, and cyg_thread_setbits() only
    Grant> calls it if the target thread is in the flag's waitqueue.

    Grant> I'm not wrong am I?

I have taken a look at this, and tried to reproduce it with a simple
testcase. I am afraid I cannot reproduce the problem: the
cyg_flag_timed_wait() always succeeds as soon as the flag is set. I
have also taken a look at the kernel code and can see no reason for
the reported behaviour.

The most obvious explanation is that it is a problem with thread
priorities. The cyg_flag_timed_wait() call may succeed as soon as the
flag is set, but the thread won't actually be resumed immediately if
there are higher-priority runnable threads, or if there is another
thread with the same priority which still has part of its timeslice to
run. For the latter scenario you would see something similar to what
you describe: some number of system clock ticks after the flag is set
the current thread's timeslice would expire, the other thread would be
resumed, and only then would the cyg_flag_timed_wait() appear to
return.

I would need a testcase before investigating any further.

Bart
    
-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2010-01-02 20:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-02 17:00 [ECOS] " Grant Edwards
2009-12-23 16:01 ` [ECOS] " Grant Edwards
2010-01-02 20:14   ` Bart Veer [this message]
2010-01-03 15:41     ` Grant Edwards

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=pnd41sz2ln.fsf@delenn.bartv.net \
    --to=bartv@ecoscentric.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=grant.b.edwards@gmail.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).