Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 23 Jun 1999 20:10:56 GMT
|
Viewed:
|
1158 times
|
| |
|
|
"John A. Tamplin" wrote:
>
> On Wed, 23 Jun 1999, Ola Liljedahl 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.
>
> An ISR can certainly modify data that is used by the executing code. For
> example, if it doesn't save registers that are used the interrupted code
> will certainly be affected. In fact, the ISR is of little use if it doesn't
> modify data that can be accessed from non-ISR code.
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.
#include "ose.h"
#define MSG 100
struct Msg
{
SIGSELECT sigNo;
int data;
/* more elements... */
};
union SIGNAL
{
SIGSELECT sigNo;
struct Msg msg;
};
OS_PROCESS(int_proc)
{
/* Interrupt process scheduled by an interrupt. */
/* Allocate a signal (OSE messages) and send to pri_proc. */
union SIGNAL *sig = alloc(sizeof(struct Msg), MSG);
sig->msg.data = some_hw_register;
send(&sig, pri_proc_);
}
OS_PROCESS(pri_proc)
{
/* Prioritized process. */
for (;;)
{
static const SIGSELECT sigsel[] = { 1, MSG };
/* Wait until a proper signal is received. */
union SIGNAL *sig = receive(sigsel);
/* Do something with message, then free it. */
free_buf(&sig);
}
}
>
> > I did not mean synchronous communication between different processes
> > (or threads). I mean that the effect on the receiving process is
> > synchronous to that process (i.e. the effect is noticed when the
> > receiving process wants to see this effect). IPC can still be
> > asynchronous, i.e. process A can send a message to process B
> > without them being synchronized but process B will not detect
> > this event until it tries to receive that message. Process B is
> > not asynchronously affected by the message sending. This as a
> > contrast to process A Unix-signalling process B where B is affected
> > regardless where it is executing.
>
> This approach reduces to a polling approach, where the only time a process
> is aware of an external event is when it asks about that event. Clearly,
> there are times when polling is simply not sufficient.
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.
> Unix-style signal handling can achieve the safety you desired in your
> original message, in a way very similar to enforcing safety with ISRs
> (disabling interrupts appropriately). Granted, some versions were broken
> in this regard and it can be difficult for a beginning programmer to get
> right, but I doubt any beginning programmers are wanting to use LegOS anyway.
This equivalent to every application writer designing and coding
device drivers. I don't think that is good for productivity and
quality.
> I think if you want a simpler approach which is safe yet more efficient than
> polling you should consider the Java approach of using monitors. The bottom
> line is that concurrent programming is easy to screw up, and there are
> various tools to solve the underlying issues.
Don't even mention Java. But monitors are at least a higher
abstraction level. But it is still a shared memory concept.
--
Ola Liljedahl
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) An ISR can certainly modify data that is used by the executing code. For example, if it doesn't save registers that are used the interrupted code will certainly be affected. In fact, the ISR is of little use if it doesn't modify data that can (...) (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
|
|
|
|
