Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 23 Jun 1999 20:22:12 GMT
|
Viewed:
|
1203 times
|
| |
|
|
On Wed, 23 Jun 1999, Ola Liljedahl wrote:
> In OSE interrupt processes (first class processes, that is why we
> don't call them ISR's) use OS mechanisms (usually messages) to
> communicate with normal processes. The OS handles all update
> of shared data structures (such as message queues).
>
> A very simple example with two processes (OSE threads) follows.
> The first processes is scheduled by a hardware interrupt (interrupt
> processes can also be scheduled by software) and sends a message
> to a prioritized process which waits only for this kind of
> messages. Asynchronous message passing with only synchronous
> effects on the involved processes. The best of two worlds.
This is the same thing as most modern RTOS use, called various things.
The terminology I use for this is FLIH/SLIH (first level interrupt handler
and second level interrupt handler). Coupled with lock priority inheritance,
it makes for a very responsive system.
> I don't agree. OSE and it's applications use this concept all the
> time and OSE is certainly not a polling operating system. Processes
> don't ask for events, they wait to be notified when interesting
> events occur.
How would you use this approach if you wanted to do some computation in
the background until a button is pressed? One, you periodically call
the receive() function to see if an event has been sent (assuming there is
a non-blocking way to receive messages), or you have a thread which
computes while a second thread waits in receive() for a message. The first
is clearly polling, while the second involves an extra thread whose only
purpose is synchronization.
With asynchronous signals, you don't have either polling or an additional
thread.
> This equivalent to every application writer designing and coding
> device drivers. I don't think that is good for productivity and
> quality.
Like I said, there are different concurrency mechanisms and they each
have their place. Personally, I most often use a synchronous queue
and message passing, which is very close to what are arguing for. But
that doesn't mean I don't see value in other methods as well.
> Don't even mention Java. But monitors are at least a higher
> abstraction level. But it is still a shared memory concept.
In your example, the OS manages the shared memory (or copying) and
low-level synchronization for you, but it is still there.
John A. Tamplin Traveller Information Services
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
|
|
Message has 1 Reply:
 | | Re: signals / legOS internals
|
| (...) This second methed doesn't really solve anything since you still have to communicate with the compute thread from the receive thread. (...) But what can you actually do in the signal handler? Modify the state of the state of the executing (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) In OSE interrupt processes (first class processes, that is why we don't call them ISR's) use OS mechanisms (usually messages) to communicate with normal processes. The OS handles all update of shared data structures (such as message queues). A (...) (25 years ago, 23-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
|
|
|
|
