public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS]  Re: Question about cyg_flag_timed_wait()
Date: Sun, 03 Jan 2010 15:41:00 -0000	[thread overview]
Message-ID: <hhqdl5$fe6$1@ger.gmane.org> (raw)
In-Reply-To: <pnd41sz2ln.fsf@delenn.bartv.net>

On 2010-01-02, Bart Veer <bartv@ecoscentric.com> wrote:

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

I agree: I can't see any case where there would be any sort of
delay in the task being scheduled (assuming it would have
priority). 

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

Thanks for looking at it -- I'm convinced that if there is a
delay in the task being scheduled it's an application code
issue with priorities.

-- 
Grant


-- 
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-03 15:41 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
2010-01-03 15:41     ` Grant Edwards [this message]

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='hhqdl5$fe6$1@ger.gmane.org' \
    --to=grant.b.edwards@gmail.com \
    --cc=ecos-discuss@sources.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).