On Wed, Sep 23, 2020 at 11:25 AM Henrik Johansson
wrote:
> This is funny, why isn't there a panic in this case? It clearly "works" as
> in it doesn't deadlock or panics assuming a write lock isn't somehow mixed
> incorrectly.
>
Why would there be a panic? The behavior is well-defined and documen
This is funny, why isn't there a panic in this case? It clearly "works" as
in it doesn't deadlock or panics assuming a write lock isn't somehow mixed
incorrectly.
On Tue, Sep 22, 2020 at 3:56 PM 'Bryan C. Mills' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Note that a lock on a sync.
Note that a lock on a sync.Mutex or sync.RWMutex is *not* held by a
specific goroutine: it can be locked by one goroutine, then communicated by
some other means (such as being sent on a channel) and unlocked on a
*different* goroutine. (See also https://golang.org/issue/9201.)
That is: these lo
FTR, I still don't think the docs *are* ambiguous. The authoritative part is
If a goroutine holds a RWMutex for reading and another goroutine might call
> Lock, no goroutine should expect to be able to acquire a read lock until
> the initial read lock is released.
The rest is just additional exp
On Mon, Sep 21, 2020 at 2:06 PM Henrik Johansson
wrote:
> Ambiguous docs however aren't generally good in any way. This came up as a
> consequence of real code being changed by a new very skilled developer and
> there was quite a bit discussion that could have been avoided with clearer
> docs.
>
A lot can be argued ;)
Ambiguous docs however aren't generally good in any way. This came up as a
consequence of real code being changed by a new very skilled developer and
there was quite a bit discussion that could have been avoided with clearer
docs.
We have sorted the issue I mostly wanted to
> Is this simply a recommendation or should the docs be updated to clarify what
> this means?
perhaps the latter, although that question only seems to come up once
every two or so years. here's a good link:
https://groups.google.com/d/msg/golang-nuts/XqW1qcuZgKg/Ui3nQkeLV80J
the entire discussi
To elaborate a bit: You are correct in that there is a slight syntactic
ambiguity whether "this prohibits" refers to the entire sentence ("if
another goroutine might call Lock, then a second RLock might not be
acquired"), or only to the second half. I would argue the rest of the
section makes it cl
It only says that's excluded *if* you can have a concurrent Lock call.
On Mon, Sep 21, 2020 at 12:48 PM Henrik Johansson
wrote:
> Yes that's the canonical deadlock but doesn't the docs say
>
> "In particular, this prohibits recursive read locking"
>
> which it doesn't unless you mix reads and wr
Yes that's the canonical deadlock but doesn't the docs say
"In particular, this prohibits recursive read locking"
which it doesn't unless you mix reads and writes.
I get that it's not advisable but it's not prohibited either or there would
be a panic or something.
On Mon, 21 Sep 2020, 12:30 Axe
(Note, FWIW, that in particular no write locks need to be *held*. It's
enough for Lock to be *called*, it doesn't have to have returned yet)
On Mon, Sep 21, 2020 at 12:29 PM Axel Wagner
wrote:
> I feel like the docs are pretty precise in what they say and why.
>
> a blocked Lock call excludes ne
I feel like the docs are pretty precise in what they say and why.
a blocked Lock call excludes new readers from acquiring the lock.
This means, the following could happen:
Goroutine 1 calls RLock, acquires a Read-Lock
Goroutine 2 calls Lock, blocking
Goroutine 1 calls RLock again, blocking (as n
12 matches
Mail list logo
