On Tue, Mar 21, 2017 at 2:35 AM, T L <[email protected]> wrote: > > On Tuesday, March 21, 2017 at 7:33:34 AM UTC+8, Ian Lance Taylor wrote: >> >> On Sat, Mar 18, 2017 at 12:03 PM, T L <[email protected]> wrote: >> > >> > At the end of sync/atomic package docs, it says >> > >> > On x86-32, the 64-bit functions use instructions unavailable before the >> > Pentium MMX. >> > >> > >> > On non-Linux ARM, the 64-bit functions use instructions unavailable >> > before >> > the ARMv6k core. >> > >> > >> > So when running Go programs which call the 64-bit atomic functions on >> > above >> > mentioned machines, programs will crash? >> >> Yes, I think you will that in those cases the program will die of a >> `SIGILL` signal. >> >> >> > If it is true, is it good idea to add a compiler option to convert the >> > 64-bit function calls to mutex calls? >> >> It's possible, but I don't think it's a good idea. When was the last >> time you saw an x86 that did not support the Pentium MMX instruction >> set? >> >> >> > And is it possible to do the conversions at run time? >> >> That too is possible. >> >> >> > And I read from somewhere which says Go authors are some regretted to >> > expose >> > the atomic functions, >> > >> > for these functions are intended to be used in standard packages >> > internally. >> > >> > So is it a good idea to recommend gophers to use mutex over atomic and >> > convert some mutex calls to atomic calls atomically by compiler? >> >> Mutexes and atomic operations are different. You can implement atomic >> operations using mutexes, but you can't easily implement mutexes using >> atomic operations. A better way to think of it is that efficient >> mutexes require atomic operations to work, but the mutex code is not >> just the atomic instructions. For example, there is no common used >> atomic instruction that implements a mutex lock that suspends the >> goroutine until the mutex is unlocked. >> >> Ian > > > But at least for some special cases, is it possible? For example: > > func (v *T) GetX() int { > v.mutex,Lock() > defer v.mutex.Unlock() > return v.x > } > > func (v *T) SetX(x int) { > v.mutex,Lock() > v.x = x > v.mutex.Unlock() > } > > If this is possible, then the atomic package don't need to be exposed.
Sorry, I didn't express myself well. It's definitely possible, as you say. But it would be very misleading for anyone expecting an atomic instruction to call functions like the ones you wrote, as the functions you wrote are orders of magnitude slower. That's not your fault, of course, it's just inevitable. So while you are certainly correct that the sync/atomic package does not need to be exposed, we shouldn't think that it can be replaced with the sync package. It can't be, because the performance matters. But it would be reasonable to argue that the performance is not worth the complexity. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
