Subject:
|
Re: LegOS 0.2.5 and LNP
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 24 Jan 2001 21:32:23 GMT
|
Viewed:
|
1699 times
|
| |
|
|
> > 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.
That's true. I've noticed it. I was speaking of PC implementation.
> 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.
Ok, perfect. I vote for the semaphore implementation. I also agree for
the implementation only for PC side.
> 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 :-)
I agree. It was only a strange idea before the semaphore solution.
> > volatile lnp_integrity_state_t lnp_integrity_state;
>
> Good.
Done.
I'll try to implement the semaphore for lnp_*_set_handler() and, after
some tests, I'll put the sources on sourceforge. I think that for that
time, the new instructions for Cygwin 1.1 and Win32 cross compiler
building from sources will be available too.
Bye,
Paolo.
---
"Be wiser than other people if you can, but do not tell them so." -
Lord Chesterfield
|
|
Message is in Reply To:
 | | Re: LegOS 0.2.5 and LNP
|
| (...) 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 (...) (24 years ago, 23-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
|
|
|
|
