Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 25 Jun 1999 14:20:13 GMT
|
Viewed:
|
1211 times
|
| |
|
|
Kekoa Proudfoot wrote:
>
> Ola Liljedahl <olli@enea.se> wrote:
> > But hardware interrupts schedule a different context (the interrupt
> > process or ISR) from the one already executing. A Unix-style signal
> > asynchronously signal interrupts the executing process and jumps to
> > a different location in the code that will access and possibly modify
> > the state of the same process. This makes it very difficult to maintain
> > data consistency.
>
> I think you're missing the point.
>
> Now correct me if I'm wrong, Lou --
>
> I believe the intent of the signal mechanism is to allow a way to specify a
> function to run when a system event occurs: e.g. a message arrives across
> the IR port. It is somewhat expected that all the typical user would all
When a frame or character has been received by the IR port it signals
an interrupt to the processor. The processor (OS) handles this by
invoking an ISR (Interrupt Service Routine). In OSE ISR's are
known as interrupt processes and they execute in their own context.
Interrupt processes can use almost all OS services, including signalling
semaphores and sending messages to other processes. The important
feature of OSE interrupt processes are that they execute in their own
context and normally (if the user does not design differently) do not
share data (state) with other processes.
> you would do in such a function is something simple that does *not* modify
> data - e.g. signal a semphore. Of course, the mechanism does not rule out
> a more advanced user doing something else, like using the keyword
> "volatile" in the appropriate places to make more interesting things
> happen. • Very dangerous method.
>
> The same signal mechanism will also allow users to send "POSIX signals" to
> other "processes," but personally I do not see the point in this, since all
> threads/processes are running in the same address space, so this
> functionality is not really needed.
Unix/POSIX signals can only be used for synchronization. Shared
memory/data
can only be used for data transfer. To implement IPC you need both,
update
shared memory and then signal recipient. In a sense this is how all OS's
function but most of them hide these mechanisms from the application
programmer.
>
> Seeing that it is my turn to pontificate, I should say that there are at
> least four ways to implement asynchronous notification of events, which is
> the whole topic we're really discussing here:
>
> 1) call a function asynchronously when the event occurs
Yes but what can this function reliably do???
> 2) signal a semaphore for the event when the event occurs
> 3) queue the event on an event queue when the event occurs
>
> Here is the argument for (1), which I buy into completely:
>
> - all of these can be implemented by the others
> - (1) is the simplest and the smallest
> - implement (1), if others want (2) or (3), let them implemented that using (1)
>
> The only argument against (1) might be that it is not the easiest to use,
It is not easy to use, it is dangerous and difficult to get right. It
gives only a very low level of funtionality.
> so naturally the question is what to implement on top of (1) for the
> "typical user"? I think the following API would be nice:
>
> #define EV_ ... // event mask bits
>
> wait_event(int mask);
>
> wait_event waits for any event specified by the mask to occur, returns when
> that has happened; implementation can be made very efficient on top of (1)
>
> This is mechanism I chose to implement in the "unreleased custom version"
> of Librcx I keep mentioning - a version that will get released at some
> point, when it's all done, but I'm in no hurry.
I must write more about OSE message passing. Stay tuned.
--
Ola Liljedahl
|
|
Message has 1 Reply:
 | | Re: signals / legOS internals
|
| Ola, I do not see why you persist. I understand that a signal handler is very low level, that it is difficult to use right, that it only allows some things and not others, unless you're very careful. But you still missed my point, which was this: (...) (25 years ago, 25-Jun-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) I think you're missing the point. Now correct me if I'm wrong, Lou -- I believe the intent of the signal mechanism is to allow a way to specify a function to run when a system event occurs: e.g. a message arrives across the IR port. It is (...) (25 years ago, 24-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
|
|
|
|
