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

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 22 of 23 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 9, '12 at 11:57p
activeOct 24, '12 at 8:33p
posts23
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase