Subject:
|
Re: LegOS 0.2.5 and LNP
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Tue, 23 Jan 2001 23:39:48 GMT
|
Viewed:
|
1402 times
|
| |
|
|
"Paolo Masetti" <paolom@pragmanet.it> writes:
> Yes, but I'm not sure what could happen if I change those
> addresses in the middle of the execution, and the old handler
> code is gone...
On the RCX the LNP handlers are called from an interrupt handler, so after
the execution of lnp_*_set_handler() you can safely assume that the old
handler will not be called any more.
On a PC things are different, there is a problem. I didn't notice it
because my code handles that case for free, just the way it handles all the
other asynchronous things :-). You can never be sure that your removed
handler isn't going to be called once more, as a context switch may happen
between the JSR of the caller (lnp_receive_packet) and the first
instruction of the callee.
I think the only way to avoid race conditions on a PC is to add a semaphore
(or a mutex). All the code of lnp_*_set_handler should be wrapped in a
sem_wait()-sem_post(), and the same applies to the `switch' instruction
in lnp_receive_packet().
There is a caveat in this. The user's handler should not block and wait
for another thread in order to avoid deadlock (a call of a
lnp_set_*_handler() cause the main program to wait for the exiting of the
handler). This restriction already applies to the RCX, so it shouldn't
hurt.
What do you think of it?
> I think that the handler code function initializer
> (lnp_*_set_handler) instead should be sure that handler functions
> addresses are written with Interrupt disabled or a sort of. Is it
> needed a sem_lnp_address too?
Yes (see above). But only on the PC (the RCX is kinda slow, so it's better
to keep the code short :-).
> in a program doesn't it? I'm quite sure that if someone change
> those handlers without passing from LNP_DUMMY_ADDRESSING (in a
> sort of logical pause in processing LNP packets) could have some
> other problems... We could check against it before assigning the
> new handler...
>
> What about a new version of:
>
> lnp_integrity_set_handler(lnp_integrity_handler_t handler)
> and
> lnp_addressing_set_handler(unsigned char port,
> lnp_addressing_handler_t handler)
>
> that returns an error and do not change handlers if the handler
> is not null?
I don't see how this could avoid a race condition. After calling
lnp_*_set_handler() to remove a handler you still don't know if an
execution of your handler is paused by a context switch. (Perhaps I
don'see because I'm blind :-)
> volatile lnp_integrity_state_t lnp_integrity_state;
Good.
bye
Bernardo
|
|
Message has 1 Reply:
 | | Re: LegOS 0.2.5 and LNP
|
| (...) after (...) old (...) That's true. I've noticed it. I was speaking of PC implementation. (...) semaphore (...) in a (...) instruction (...) wait (...) of the (...) shouldn't (...) Ok, perfect. I vote for the semaphore implementation. I also (...) (24 years ago, 24-Jan-01, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: LegOS 0.2.5 and LNP
|
| (...) was like this: (...) you reload (...) PC, as you are (...) thing is to read (...) place of (...) optimize it and (...) what you want (...) attribute. Yes, but I'm not sure what could happen if I change those addresses in the middle of the (...) (24 years ago, 22-Jan-01, to lugnet.robotics.rcx.legos)
|
9 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
|
|
|
|
