 | | Re: RCX Programming Questions and Sensor Ideas
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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)
|
