 | | Re: NQC 2.0 and some math questions
|
|
(...) I'm going from memory here, so I may miss a detail... int lock; #define TASK_BIT(task_num) (1 << task_num) void acquire_lock(int task_num) { while(1) { // wait for lock to be clear while(lock); // try to own it lock |= TASK_BIT(task_num); // (...) (25 years ago, 2-Oct-99, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.0 and some math questions
|
|
Your proposed solution is susceptible to the "lockstep starvation" problem. Lockstep starvation happens when two tasks try to get the lock at the same time and execute the same code in lock step, like so: task 1: lock |= 2; task 2: lock |= 4; task (...) (25 years ago, 2-Oct-99, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.0 and some math questions
|
|
(...) This only works if |= is atomic, though. Is it? Cheers, Ben. -- (URL) grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less (...) (25 years ago, 2-Oct-99, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.0 and some math questions
|
|
(...) Yes, |= is atomic. At the bytecode level you always OR from some source into a destination variable. Dave (25 years ago, 2-Oct-99, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.0 and some math questions
|
|
(...) You're right - I forgot the delay (that's what I get for typing code from memory). Yeah, 'test and set' is the best solution, but unfortunately the RCX doesn't have one. The bitflag stuff is a little ugly for my tastes, which is why NQC does (...) (25 years ago, 2-Oct-99, to lugnet.robotics.rcx.nqc)
|
