This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: How to know whether currently there is any thread ready to run?
- From: "Young Jay" <young_jay at sohu dot com>
- To: "sandeep kumar" <sandeep at codito dot com>
- Cc: <jifl at eCosCentric dot com>, <ecos-discuss at sources dot redhat dot com>
- Date: Mon, 8 Mar 2004 13:21:05 +0800 (CST)
- Subject: Re:[ECOS] How to know whether currently there is any thread ready to run?
Sandeep:
Thank you very much for you suggestion. Your analysis gives me helpful reference,
and I have found solution to our platform. Also thank Jonathan for your help.
Best regards,
Young Jay
----- Original Message -----
From: sandeep kumar
To: Young Jay ;Jonathan Larmour
Cc: ecos-discuss@sources.redhat.com
Subject: Re: Re:[ECOS] How to know whether currently there is any thread ready to run?
Sent: Fri Mar 05 17:47:34 CST 2004
> > Thank you for your reply. I tried, but it doesn't give the result I need.
> > When I referred to an eCos book, "Embedded Software Development with eCos",
> > which is written by Anthony J. Massa, I noticed that the function
> cyg_thread_self
> > returns the handle of current thread, and can only be called by current
> thread.
> >
> > Thus I think I can't use this function in interrupt_end or RTC's DSR to seek
> the
> > current thread ready to run. Right?
> > > >>
> > > >>In my design, when performing the real time clock interrupt ISR, I'd
> > > >>like to know if there is any thread just getting ready to run after a
> > > >>time delay. Thus I can decide whether the system power mode should be
> > > >>changed. Is there a function designed for this need? Thanks a lot for
> > > >>you concern.
>
> different answers to your problem are possible, depending upon what is this
> *time delay* you are talking about (and also whether i understand what you
> intend to do) --
> are you interested in knowing that there will definitely be a thread ready to
> run after some time X?
> in this case you might possibly examine the alarms that are set (if any) and
> do some jugglary to figure
> out that if any alarm will trigger leading to runnable threads b/w
> current-time and current-time+X.
>
> but say, there are no alarms set or none is likely to trigger leading to
> runnable thread(s), in time
> window mentioned above - will it be right to change the system power mode now?
> (may be, in your
> setup it is. granularity of X can also be a deciding factor) what if some
> threads continue to run
> otherwise too and/or they/new-thread add another alarm(s) that trigger in this
> time-window?
>
> if what you mean is - just to find out if there is any runnable thread other
> than idle-thread, after
> currently executing non-idle thread (but remember that current thread might
> continue being runnable
> further and might get loaded again if no-other non-idle runnable thread is
> there )..
> you can try adding a new function peek_next_schedulable_thread (similar to
> implementation specific
> schedule function, and it doesn't update the thread-queue but just peeks the
> head rather than getting the
> head) whose outcome you can compare to find if there is any non-idle thread
> available to run or not.
>
> hope something makes sense as per your requirements!
> sandeep
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss