-
Notifications
You must be signed in to change notification settings - Fork 18.3k
Closed
Labels
Description
This has come up several times on the mailing list. Looking for something like this to be provided in sync.Mutex: func (m *Mutex) TryLock() (locked bool) { locked = atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) if locked && raceenabled { raceAcquire(unsafe.Pointer(m)) } return } Now you could use CompareAndSwapInt32 yourself. But it gets tricky when you need to use Lock in one function, and TryLock in another on the same mutex. The typical use-case is something like this: if m.TryLock() { // do something } else { // do something else } It's very similar to select default for channels: select { case <-c: // do something default: // do something else } The difference being that with such a function you can do this with a primitive. Other languages provide this functionality: Java: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Lock.html#tryLock() Objective-C: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSLock_Class/Reference/Reference.html#//apple_ref/occ/instm/NSLock/tryLock A "LockBeforeTime" would also be useful, but I understand that's more difficult to implement.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
robpike commentedon Aug 13, 2013
Comment 1:
Labels changed: added priority-someday, removed priority-triage, go1.2maybe.
robpike commentedon Aug 13, 2013
Comment 2:
Status changed to Accepted.
robpike commentedon Aug 13, 2013
Comment 3:
Labels changed: added feature.
lukescott commentedon Aug 13, 2013
Comment 4:
adg commentedon Aug 13, 2013
Comment 5:
lukescott commentedon Aug 13, 2013
Comment 6:
adg commentedon Aug 13, 2013
Comment 7:
lukescott commentedon Aug 13, 2013
Comment 8:
adg commentedon Aug 13, 2013
Comment 9:
cznic commentedon Aug 13, 2013
Comment 10:
dvyukov commentedon Aug 13, 2013
Comment 11:
nigeltao commentedon Aug 14, 2013
Comment 13:
rsc commentedon Nov 27, 2013
Comment 14:
Labels changed: added go1.3maybe.
rsc commentedon Nov 27, 2013
Comment 15:
Labels changed: removed feature.
rsc commentedon Dec 4, 2013
Comment 16:
Labels changed: added release-none, removed go1.3maybe.
rsc commentedon Dec 4, 2013
Comment 17:
Labels changed: added repo-main.
adg commentedon Dec 18, 2014
It's been more than a year since the last comment on this issue, and nobody has provided a compelling argument for this feature. I don't think it's going to happen.
beatgammit commentedon Mar 31, 2015
In case someone else comes along here, I think this would work for a general-purpose non-blocking semaphore:
It's not as efficient as it could be, but it's very simple and easily understandable as it uses basic language features (and is flexible enough to allow any type in the channel).
alkemir commentedon May 1, 2015
How about creating a pool of resources (say connections or buffers) ?
Code would look like this:
This is like sync.Pool but for resources that you don't want deallocated when free.
I guess the alternative using channels would have the resources send themselves
over a channel when free? Something like this:
The good side of using channels is that the "WaitGroup logic" is straightforward. Also, you dont need to iterate over the busy resources. The only disadvantage with using channels that I can see is that freeing a resource is locking if you reach channel capacity. But then again, you can always call freeResource in a goroutine if you can't estimate the buffering you are going to need.
Although this would seem weird, considering you have MAX_POOL_SIZE, think of a case when MAX_POOL_SIZE is a soft limit, that is, you have two different calls for adquiring resources;
getResource()
andgetResourceNow()
. The second method does not honor the limit and is used on crucial situations when you cannot be bothered by that limit.Would this pattern be correct?
ianlancetaylor commentedon May 1, 2015
If you are asking a question, please ask on the mailing list golang-nuts@googlegroups.com. Please don't ask questions on the issue tracker. And particularly please don't comment on closed issues; if you want to reopen one, bring that up on the mailing list as well. Thanks.