Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 23 Jun 1999 20:48:32 GMT
|
Viewed:
|
1141 times
|
| |
|
|
"John A. Tamplin" wrote:
>
> On Wed, 23 Jun 1999, Ola Liljedahl wrote:
>
> > 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.
This second methed doesn't really solve anything since you still have
to communicate with the compute thread from the receive thread.
> With asynchronous signals, you don't have either polling or an additional
> thread.
But what can you actually do in the signal handler? Modify the state
of the state of the executing process? Then you have to synchronize
these accesses with the original thread of control (using the sigmask-
facility). This is the dangerous path again. Or you can terminate the
executing process. In OSE you can do that too from another process. I
don't see any real need for Unix-style signals, especially not in light
of all its disadvanatges.
> 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.
I agree that one method is not sufficient for all needs. In OSE we
use other methods of syncronization and communication too.
> > 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.
Handled only by the OS just as the MMU is handled only by the OS.
You just don't want every application (esp. application writer) to
perform these operations. The correct implementation is much too
difficult (not only functionality but also properties such as
bounded execution time etc.) and the result of improper code is
probably fatal.
A feature of OSE and its message passing is that it transparently
scales from shared memory designs to protected memory design to
networked (loosely coupled) designs. The applications do not need
to know the location of other processes they communicate with.
--
Ola Liljedahl
|
|
Message is in Reply To:
 | | Re: signals / legOS internals
|
| (...) 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 (...) (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
|
|
|
|
