Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 23 Jun 1999 19:50:34 GMT
|
Viewed:
|
1226 times
|
| |
|
|
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.
> 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.
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.
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.
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
|
| (...) 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)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) 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 (...) (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
|
|
|
|
