Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 26 Jun 1999 19:58:21 GMT
|
Viewed:
|
1075 times
|
| |
|
|
Lou Sortman <theball@bigfoot.com> wrote:
> > But why do you need signals to do that? If you are a thread, and you have
> > a reference to another thread (pid, pointer to thread data structure,
> > whatever), then there should be functions for you to manipulate the thread
> > you have a pointer to, including suspending and resuming that thread.
>
> That is true. Signals would give the task the opportunity to stop/start
> tasks under its control, though, without the task that makes the calls
> having to know about that relationship. That could be done through
> dedicated callbacks in the process structure, but by that point, you've
> almost got signals anyway.
What am I missing? Why do you need callbacks in the process structure? I
was thinking if you can reference the thread, you can just call a system
function (e.g. suspend(thread)), and that will suspend the thread. You do
not need callbacks anywhere to do this; suspend(thread) just removes the
specified thread from whatever queue it is waiting on and puts it on a
suspended list.
Or maybe you want signals because you do not want the thread to be
suspended immediately, but you want the thread to be able to recognize that
some other thread wants it to suspend itself, and take action accordingly
(so maybe it can free locks or something)? In that case, you are right,
you need signals to do that.
> > The default thing hooked into a vector (if anything is hooked into the
> > vector) is supposed to be some other part of the library, something
> > that provides higher level event notification to any number of threads.
>
> That is the way I'd do it anyway. Have a thread whose sole job it is to
> manage a resource and communicate with any interested threads. This is
> how I implemented motor ramping.
>
> With the vectored approach, it may not necessarily need to be a thread.
Right, I was thinking of one or more system level functions (which are not
associated with any thread) that search a list, moving the appropriate
waiters to the ready queue or taking some other appropriate action. This
function (like most vectored functions) would run as part of the ISR.
-Kekoa
|
|
Message has 2 Replies:
 | | Re: signals / legOS internals
|
| (...) Now keep in mind that this is coming from someone who won't take Duke's OS class until next spring- is there any reason the current semaphore implementation couldn't be used for a large percentage of these tasks? I.E., thread A checks (or uses (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
| | | Re: signals / legOS internals
|
| (...) Yes, that is it. A classic example is a full screen app such as vi. When being stopped, vi sets the terminal mode to something generic and saves any screen info that it needs. When resumed, it sets the terminal mode back to what it wants and (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) Cool. I will proceed. (...) Yup. I was out of the loop for awhile, and am once again whompin' on this project. (...) That is true. Signals would give the task the opportunity to stop/start tasks under its control, though, without the task that (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
32 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
