FAQ
Hi Guys,
im thinknig about "garbage" collection algorithm that'll scan the memory
that needs to be collected looking for expired items. The idea is to scan
the memory that is being constantly written to, without locking, then after
a potential expired item is found, use mutex to be sure that the value that
is read is actually correct. Something like "double-read".

Example from line 24. It doesn't work in playground, only when compiled, of
course race detector goes crazy.

https://play.golang.org/p/vF4P0kyRrx

I read that it is generally not advised to do that, can i corrupt eg. CPU
cache this way, so after locking i'll still get "incorrect" value that is
corrupted? Is there any potential problem with that approach, in C /
Golang? Any way to "tell" race detector to be silent for some vars.

Thanks.

--
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/d/optout.

Search Discussions

  • Dmitry Vyukov at Apr 20, 2015 at 12:45 pm

    On Mon, Apr 20, 2015 at 3:37 PM, Slawomir Pryczek wrote:
    Hi Guys,
    im thinknig about "garbage" collection algorithm that'll scan the memory
    that needs to be collected looking for expired items. The idea is to scan
    the memory that is being constantly written to, without locking, then after
    a potential expired item is found, use mutex to be sure that the value that
    is read is actually correct. Something like "double-read".

    Example from line 24. It doesn't work in playground, only when compiled, of
    course race detector goes crazy.

    https://play.golang.org/p/vF4P0kyRrx

    I read that it is generally not advised to do that, can i corrupt eg. CPU
    cache this way, so after locking i'll still get "incorrect" value that is
    corrupted? Is there any potential problem with that approach, in C / Golang?
    Any way to "tell" race detector to be silent for some vars.

    Use sync/atomic operations for unprotected reads and for writes to the
    variable. Then it becomes a legal pattern.

    --
    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/d/optout.
  • Dave Cheney at Apr 20, 2015 at 2:05 pm
    This is double checked
    locking, http://en.wikipedia.org/wiki/Double-checked_locking. It is
    generally considered unsafe.
    On Monday, 20 April 2015 22:37:09 UTC+10, Slawomir Pryczek wrote:

    Hi Guys,
    im thinknig about "garbage" collection algorithm that'll scan the memory
    that needs to be collected looking for expired items. The idea is to scan
    the memory that is being constantly written to, without locking, then after
    a potential expired item is found, use mutex to be sure that the value that
    is read is actually correct. Something like "double-read".

    Example from line 24. It doesn't work in playground, only when compiled,
    of course race detector goes crazy.

    https://play.golang.org/p/vF4P0kyRrx

    I read that it is generally not advised to do that, can i corrupt eg. CPU
    cache this way, so after locking i'll still get "incorrect" value that is
    corrupted? Is there any potential problem with that approach, in C /
    Golang? Any way to "tell" race detector to be silent for some vars.

    Thanks.
    --
    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/d/optout.
  • Slawomir Pryczek at Apr 21, 2015 at 2:47 pm
    Yes i read the Java examples about singleton pattern and pre-checking ...
    understand why it might be unsafe, probably because the pointer could be
    not null but still partially written to and returned. I have a little
    different situation, i mean the data is double checked before it is used,
    instead of checking before generation...

    JAVA singleton sample:
    if not null return
    lock
    if null generate
    unlock
    return

    My code:
    if not expired, return [skip]
    if expired lock
    if still expired delete
    unlock

    So the first code isn't 100% safe because write to pointer could not be
    atomic in C (if i get that correctly)... problem with second example would
    be CPU cache corruption or some compiler optimization...

    Any more comments on that?

    Thanks.

    W dniu poniedziałek, 20 kwietnia 2015 14:37:09 UTC+2 użytkownik Slawomir
    Pryczek napisał:
    Hi Guys,
    im thinknig about "garbage" collection algorithm that'll scan the memory
    that needs to be collected looking for expired items. The idea is to scan
    the memory that is being constantly written to, without locking, then after
    a potential expired item is found, use mutex to be sure that the value that
    is read is actually correct. Something like "double-read".

    Example from line 24. It doesn't work in playground, only when compiled,
    of course race detector goes crazy.

    https://play.golang.org/p/vF4P0kyRrx

    I read that it is generally not advised to do that, can i corrupt eg. CPU
    cache this way, so after locking i'll still get "incorrect" value that is
    corrupted? Is there any potential problem with that approach, in C /
    Golang? Any way to "tell" race detector to be silent for some vars.

    Thanks.
    --
    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/d/optout.
  • Egon at Apr 21, 2015 at 3:11 pm

    On Tuesday, 21 April 2015 17:46:57 UTC+3, Slawomir Pryczek wrote:
    Yes i read the Java examples about singleton pattern and pre-checking ...
    understand why it might be unsafe, probably because the pointer could be
    not null but still partially written to and returned. I have a little
    different situation, i mean the data is double checked before it is used,
    instead of checking before generation...

    JAVA singleton sample:
    if not null return
    lock
    if null generate
    unlock
    return

    My code:
    if not expired, return [skip]
    if expired lock
    if still expired delete
    unlock

    So the first code isn't 100% safe because write to pointer could not be
    atomic in C (if i get that correctly)... problem with second example would
    be CPU cache corruption or some compiler optimization...

    Any more comments on that?
    https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong

    Thanks.

    W dniu poniedziałek, 20 kwietnia 2015 14:37:09 UTC+2 użytkownik Slawomir
    Pryczek napisał:
    Hi Guys,
    im thinknig about "garbage" collection algorithm that'll scan the memory
    that needs to be collected looking for expired items. The idea is to scan
    the memory that is being constantly written to, without locking, then after
    a potential expired item is found, use mutex to be sure that the value that
    is read is actually correct. Something like "double-read".

    Example from line 24. It doesn't work in playground, only when compiled,
    of course race detector goes crazy.

    https://play.golang.org/p/vF4P0kyRrx

    I read that it is generally not advised to do that, can i corrupt eg. CPU
    cache this way, so after locking i'll still get "incorrect" value that is
    corrupted? Is there any potential problem with that approach, in C /
    Golang? Any way to "tell" race detector to be silent for some vars.

    Thanks.
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 20, '15 at 12:37p
activeApr 21, '15 at 3:11p
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase