> locks are not necessary between threads in the same proc
> because only one of them can run at a time and they are
> cooperatively scheduled.
It is important to note that using cooperatively scheduled threads
doesn't automatically mean you don't need locking. If your
threads can go to sleep with some resources in intermediate states
that other threads should not observe, then you need locking.
It's just that instead of using Locks, which do not yield the current
thread, you should use QLocks, which do.
The precise version of Erik's statement is this:
For resources shared only by threads in a single proc, Locks are either
unnecessary (because there is no true concurrent access due to the
cooperative scheduling) or incorrect (because spinning won't
let the other thread run, so the lock will never be unlocked).
If the Lock would always protect a tiny critical section that
obviously doesn't yield or call any function that might yield
(qlock, alt, send, recv, etc.), then it's unnecessary. Otherwise,
it's incorrect, and you should be using QLocks.
Russ
