 | | Re: RCX Programming Questions and Sensor Ideas —Paul Haas
|
| | | (...) Check and set do not have to be atomic, they have to be ordered. The sequence is: Check all flags, when clear, set our flag, check all flags again, if only ours is set, do stuff. 1. You can dedicate a task to managing semaphores. I described (...) (26 years ago, 11-Nov-98, to lugnet.robotics)
|
| | | |
| | | | | Re: RCX Programming Questions and Sensor Ideas —Ben Laurie
|
| | | | (...) It isn't guaranteed to work, either, though it is likely to in the end. This is because two processes can conspire to always have r31 == 2 when you test for r31 == 1. Cheers, Ben. (26 years ago, 11-Nov-98, to lugnet.robotics)
|
| | | | |
| | | | | | Re: RCX Programming Questions and Sensor Ideas —Paul Haas
|
| | | | (...) Oops. I don't know how the scheduler in the RCX works. It might execute 1 opcode from each task in order. If 2 tasks get in sync, then they will never leave the semaphore code as written. Here's a fixed version. I added a random backoff. (...) (...) (26 years ago, 11-Nov-98, to lugnet.robotics)
|
| | | | |
| | | | | | Re: RCX Programming Questions and Sensor Ideas —Todd Lehman
|
| | | | (...) Paul, Are you sure you want to sleep before decrementing r31? As written, r31 is always >= 1 during the sleep -- which prevents any other tasks from obtaining a lock on the resource during this sleep time. In other words, once any two tasks (...) (26 years ago, 11-Nov-98, to lugnet.robotics)
|
| | | | |
| | | | | | Re: RCX Programming Questions and Sensor Ideas —Paul Haas
|
| | | | (...) I think "oops" applies in this case. Your fix looks correct. (...) It doesn't have to be random, just each task needs a different delay. This is easy, since each task has to run its own version of the code. For task 3 insert 3 noops, for task (...) (26 years ago, 11-Nov-98, to lugnet.robotics)
|
| | | | |
| | | | | | Re: RCX Programming Questions and Sensor Ideas —Todd Lehman
|
| | | | (...) Does that support an arbitrary number of tasks? If there are n tasks numbered 1 to n, and task k delays for k cycles on failure, I think you still have to be careful to make sure that the number of tasks n is smaller than the loop overhead h (...) (26 years ago, 11-Nov-98, to lugnet.robotics)
|
| | | | |
