(*sync.Mutex).Lock() and Unlock() do.
If you really want to have a pointer Mutex in objects that are meant to be
copied, you're not going to be able to do it without the cumbersome new in
each literal. The standard way to deal with this is to make a function that
constructs instances of the object.
On Thursday, August 27, 2015 at 4:41:57 PM UTC-7, James Aguilar wrote:
Hrm. I think you're going to want to be passing around pointers of this
thing anyway. Otherwise, you'll effectively have copies of the thing
running around, all being protected by the same Mutex. Like so:
http://play.golang.org/p/VvKXDXr5eQ
--Hrm. I think you're going to want to be passing around pointers of this
thing anyway. Otherwise, you'll effectively have copies of the thing
running around, all being protected by the same Mutex. Like so:
http://play.golang.org/p/VvKXDXr5eQ
On Thursday, August 27, 2015 at 4:35:12 PM UTC-7, Gbr wrote:
No, unfortunately. If you make sync.Mutex a direct embedded field (as
opposed to a pointer field), you loose implementation of Y -- sync.Locker
requires a pointer receiver.
No, unfortunately. If you make sync.Mutex a direct embedded field (as
opposed to a pointer field), you loose implementation of Y -- sync.Locker
requires a pointer receiver.
On Thursday, August 27, 2015 at 4:24:39 PM UTC-7, James Aguilar wrote:
type X struct {
Value int
sync.Mutex
}
If I understand you correctly, you want to avoid having to type out the
"new" for the mutex each time you use the type literal. This should work,
shouldn't it?
type X struct {
Value int
sync.Mutex
}
If I understand you correctly, you want to avoid having to type out the
"new" for the mutex each time you use the type literal. This should work,
shouldn't it?
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.
