FAQ

On 2012/10/15 21:35:07, gri wrote:
The only safe way I see at the moment to do this is to lock/unlock the
mutex for each new table entry. That's not hard, but I don't know if it's
worth it. I am worried about correctness of lock-free approaches (using
package atomic) that operate on slice elements. But I'm happy to be proven
otherwise. Either way, I believe what we have now is correct if possible
not optimal performance-wise. But again, I don't think there's an immediate
urgency for this to be fixed as I am not aware of programs caring about
this too much at the moment.
- gri

It's quite easy to implement w/o atomic ops on slice elements. That's
what I had in mind:
https://codereview.appspot.com/6766047/diff/2001/src/pkg/math/big/nat.go


On Mon, Oct 15, 2012 at 1:51 PM, Michael Jones
wrote:
Ok. Will look. Thank you for bringing this to my attention!


On Mon, Oct 15, 2012 at 3:31 AM, Dmitry Vyukov
wrote:
It is not the case now.


On Sun, Oct 14, 2012 at 4:45 PM, Michael Jones
wrote:
Thanks! Performance wise, it is important that other goroutines be
able
to use the read-only smaller entries while a larger one is being
created.

On Sun, Oct 14, 2012 at 2:05 AM, Dmitry Vyukov
wrote:
I suggested to Robert to make the code work the way you describe.



--
Michael T. Jones | Chief Technology Advocate |
mailto:mtj@google.com | +1
650-335-5765

--
Michael T. Jones
mailto:michael.jones@gmail.com
http://www.google.com/profiles/michael.jones

https://codereview.appspot.com/6643053/

Search Discussions

  • Michael Jones at Oct 24, 2012 at 8:33 pm
    In an airport on the way to Cypress. Will look ASAP.
    On Wed, Oct 24, 2012 at 12:03 PM, wrote:
    On 2012/10/15 21:35:07, gri wrote:

    The only safe way I see at the moment to do this is to lock/unlock the
    mutex for each new table entry. That's not hard, but I don't know if it's
    worth it. I am worried about correctness of lock-free approaches (using
    package atomic) that operate on slice elements. But I'm happy to be proven
    otherwise. Either way, I believe what we have now is correct if possible
    not optimal performance-wise. But again, I don't think there's an immediate
    urgency for this to be fixed as I am not aware of programs caring about
    this too much at the moment.
    - gri


    It's quite easy to implement w/o atomic ops on slice elements. That's
    what I had in mind:
    https://codereview.appspot.com/6766047/diff/2001/src/pkg/math/big/nat.go


    On Mon, Oct 15, 2012 at 1:51 PM, Michael Jones
    wrote:
    Ok. Will look. Thank you for bringing this to my attention!


    On Mon, Oct 15, 2012 at 3:31 AM, Dmitry Vyukov
    wrote:
    It is not the case now.


    On Sun, Oct 14, 2012 at 4:45 PM, Michael Jones
    wrote:
    Thanks! Performance wise, it is important that other goroutines be
    able
    to use the read-only smaller entries while a larger one is being
    created.

    On Sun, Oct 14, 2012 at 2:05 AM, Dmitry Vyukov
    wrote:
    I suggested to Robert to make the code work the way you describe.



    --
    Michael T. Jones | Chief Technology Advocate |
    mailto:mtj@google.com | +1
    650-335-5765

    --
    Michael T. Jones
    mailto:michael.jones@gmail.com
    http://www.google.com/profiles/michael.jones


    https://codereview.appspot.com/6643053/


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 24, '12 at 7:03p
activeOct 24, '12 at 8:33p
posts2
users2
websitegolang.org

2 users in discussion

Dvyukov: 1 post Michael Jones: 1 post

People

Translate

site design / logo © 2022 Grokbase