FAQ
Ah, right. I forget that a slice is a struct with non-atomic assignment
instead of a pointer to a struct. I don't think that the order of
operations in append matters, just the struct layout in memory and the
implementation of memcpy (or whatever golang implementation X uses).
On Tuesday, April 9, 2013 2:35:00 AM UTC-7, kortschak wrote:

I don't think that's true. Not protecting the read means that you are
potentially reading a half filled internal slice struct with no guarantee
of validity. What if the location holding the len value was previously
storing something larger than both x and the actual len of the slice.
Whether this panic is now dependent on whether that read wins the race and
the order of operations in append, which is not specified.

It's true that the lock on the fast path will impact performance, but
most cases are not contentious, so it should not be that bad. I'll have a
look.

On 09/04/2013, at 5:29 PM, "Bryan Matsuo" wrote:

There is no need to lock during the first length check (it's going to
kill performance). If the slice you check is longer than you need then the
slice you index (whether or not the same slice) long enough and cannot have
been garbage collected.

http://play.golang.org/p/lKvTPIVN3m
On Tuesday, April 9, 2013 12:21:36 AM UTC-7, kortschak wrote:

Good. Thanks - I was thinking about double checking but wasn't sure.

I just did a timing diagram for the promotion - yes, I see what you
mean.
On Tue, 2013-04-09 at 09:15 +0200, Rémy Oudompheng wrote:
It's not only baroque, it is not possible to promote because virtually
any code using that would deadlock immediately.

Having to check invariants twice is the normal pattern.

Some people have proposed wrappers that check the condition twice for
you but it didn't really simplify code.

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 19 of 20 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 9, '13 at 3:00a
activeApr 24, '13 at 3:54a
posts20
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase