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 <tapi...@gmail.com <javascript:>>
> 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.
--
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.
For more options, visit https://groups.google.com/d/optout.
