Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 26 Jun 1999 20:34:14 GMT
|
Viewed:
|
1255 times
|
| |
|
|
Luis Villa wrote:
>
> 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 a wait_event to check) a semaphore before
> taking an action, and thread B can toggle said semaphore to "signal"
> thread A that it is appropriate to take the action. Obviously, this won't
> cover all situations (it won't immediately interrupt thread A under some
> circumstances, for example). However, it would seem to this untutored eye
> that it would cover most of them. Am I correct? Or is there some
> reason why it is inappropriate to use semaphores like this?
They could. In fact, there may be cases where that is exactly what you
want to do. However, that requires you to write your code to examine
the semaphore at every point where you would want to consider processing
the event. It is more work. With signals, a process can have certain
things happen (handled by the OS) without it even being accomodated by
its own code.
Also, you can do it now, but there did not used to be a good way to
communicate things such as the address of a semaphore to another
thread. No, I don't consider global variables to be a good way. Now,
at least, there is the argument list on execi.
|
|
Message is in Reply To:
 | | 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)
|
32 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
