Re: [go-nuts] Non-atomic access to m.state in sync.Mutex
the "bug" is still there. any purpose? 在2013年6月7日星期五 UTC+8 下午8:55:56 写道： > On Fri, Jun 7, 2013 at 4:31 PM, Maxim Khitrov wrote: > > Hi, > > > > I assume that the code is correct, but I'd like to understand why it's > > safe. The line "old := m.state" in Mutex.Lock()'s for loop accesses a > > variable that could be shared and updated by multiple goroutines, but > > it doesn't use atomic.LoadInt32. Is that because aligned 32-bit loads > > are atomic on all supported platforms anyway, or is there another > > reason? > > This is a bug. > > > > As a more general question, when are you required to use atomic.Load* > > functions to guarantee correct behavior? > > Whenever there are concurrent writes to the variable. > > > > If m.state was a 64-bit int, > > would you have to use LoadInt64 to support 32-bit platforms? > > > > Likewise, what if you have a pointer that's being updated in one > > goroutine, but being read in others? The update should probably be > > done using Store or CompareAndSwap functions, but do you need an > > atomic Load as well? > > Yes, one needs atomic.Load. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2aa00a97-1e95-4821-a278-b05655604799n%40googlegroups.com.
Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go
Thanks for the suggestions. I created https://github.com/jba/codec/pull/1 to address them. You can comment in more detail there if you'd like. On Wed, Jan 20, 2021 at 12:13 PM roger peppe wrote: > On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam > wrote: > >> The encoding scheme is described briefly in the README[0] and the code[1]. >> >> To answer your two specific questions, interfaces are represented as a >> pair (typeNumber, value) where typeNumber maps to a registered type. (Like >> gob, types must be registered.) Structs are represented as: startCode >> (fieldNumber value)* endCode. The field numbers are assigned by the >> generator. >> > > It might be good to be more explicit about how the field numbers are > assigned. From a brief experiment, it seems like there's not a deterministic > relationship between a struct and its wire representation, and instead the > generated field numbers are taken from the generated code file > when it's present. So ISTM that any user of this must be very careful to > preserve that file, and realise that it's not OK to generate > the codec code for a type independently. > > I'd also suggest that it would be good to fully document the syntax and > explain the trade-offs of this format and when > it might or might not be appropriate to use. > > One other question: how are the type numbers maintained as stable entities > over time? > > cheers, > rog. > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEymQsQ%3D4WkteR1t6o5TXfzp0egR%3DvsGii8On_mKBU%2B_YRM%2BfA%40mail.gmail.com.
