From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Subject: Re: [9fans] channel_lock
From: "Russ Cox" <rsc@swtch.com>
Date: Mon, 14 Jul 2008 17:04:14 -0400
In-Reply-To: <61d4bbe5c7dc2aec46ffb603ed219b88@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080714210249.08E4B1E8C1F@holo.morphisms.net>
Topicbox-Message-UUID: e6cdd72e-ead3-11e9-9d60-3106f5b1d025

> 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