On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser <he...@joshlf.com>

> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor <i...@golang.org> wrote:
>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser <he...@joshlf.com>
>> wrote:
>> >
>> > I'm playing around with implementing a wait-free channel in the runtime
>> > package, and as part of this, it'd be really nice to have double-word
>> > compare-and-swap (CAS). Barring that, however, for my purposes, it would
>> > actually be fine to have a one-word value that encodes both a pointer
>> and
>> > some extra information using bit packing. The problem, though, is that
>> if I
>> > store this value as, for example, a uintptr, the GC may not realize that
>> > it's a pointer. So my question is: are there any bits in a pointer
>> which,
>> > when modified, won't mess with the GC? Note that since this is
>> implemented
>> > in the runtime, I'm totally OK with relying on behavior specific to the
>> > current GC implementation.
>> See runtime/lfstack*.go.
> Awesome, thanks!

Actually, quick follow-up. I noticed that the lfstack implementation
side-steps the GC issue by just not keeping pointers. That might work for
me if I just store runtime.g pointers, but that raises another question:
can the GC ever free g's, or are they just explicitly freed when a
goroutine quits? That is, is it safe for me to store a pointer/counter
hybrid like in lfstack - where that pointer is a *g - and assume that the
GC won't collect the g from out from under me?

>> Ian

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to