README
¶
Now that's what I call sync!
Are you ready for X of today's hotest Go synchronization primitives in an all new power-pack collection?
Move into a new dimension with Go's best concurrency tools.
Now you can have all your favorite hits: right here, right now.
Chart-toppers from:
- sync
- golang.org/x/sync
- tailscale.com/syncs and more!
There's never been a concurrency collection like this before, until now!
To order call the number on your screen or send check or money order for the amount shown plus shipping and handling.
Must be 18 or older to call.
RUSH DELIVERY AVAILABLE Send $0 For License + $0 S+H
P.O. Box 17070 Colorado Springs, CO 80935 1-800-554-1600
Allow 3 to 4 seconds delivery / Money Back Guarantee
Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type ErrGroup ¶
An ErrGroup is a collection of goroutines working on subtasks that are part of the same overall task.
A zero Group is valid, has no limit on the number of active goroutines, and does not cancel on error.
type Map ¶
type Map[K comparable, V any] syncs.Map[K, V]
Map is a Go map protected by a sync.RWMutex. It is preferred over sync.Map for maps with entries that change at a relatively high frequency. This must not be shallow copied.
type Mutex ¶
A Mutex is a mutual exclusion lock. The zero value for a Mutex is an unlocked mutex.
A Mutex must not be copied after first use.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m. A successful call to TryLock is equivalent to a call to Lock. A failed call to TryLock does not establish any “synchronizes before” relation at all.
type Once ¶
Once is an object that will perform exactly one action.
A Once must not be copied after first use.
In the terminology of the Go memory model, the return from f "synchronizes before" the return from any call of once.Do(f).
type Pool ¶
A Pool is a set of temporary objects that may be individually saved and retrieved.
Any item stored in the Pool may be removed automatically at any time without notification. If the Pool holds the only reference when this happens, the item might be deallocated.
A Pool is safe for use by multiple goroutines simultaneously.
Pool's purpose is to cache allocated but unused items for later reuse, relieving pressure on the garbage collector. That is, it makes it easy to build efficient, thread-safe free lists. However, it is not suitable for all free lists.
An appropriate use of a Pool is to manage a group of temporary items silently shared among and potentially reused by concurrent independent clients of a package. Pool provides a way to amortize allocation overhead across many clients.
An example of good use of a Pool is in the fmt package, which maintains a dynamically-sized store of temporary output buffers. The store scales under load (when many goroutines are actively printing) and shrinks when quiescent.
On the other hand, a free list maintained as part of a short-lived object is not a suitable use for a Pool, since the overhead does not amortize well in that scenario. It is more efficient to have such objects implement their own free list.
A Pool must not be copied after first use.
In the terminology of the Go memory model, a call to Put(x) "synchronizes before" a call to Get returning that same value x. Similarly, a call to New returning x "synchronizes before" a call to Get returning that same value x.
type RWMutex ¶
A RWMutex is a reader/writer mutual exclusion lock. The lock can be held by an arbitrary number of readers or a single writer. The zero value for a RWMutex is an unlocked mutex.
A RWMutex must not be copied after first use.
If any goroutine calls Lock while the lock is already held by one or more readers, concurrent calls to RLock will block until the writer has acquired (and released) the lock, to ensure that the lock eventually becomes available to the writer. Note that this prohibits recursive read-locking.
In the terminology of the Go memory model, the n'th call to Unlock "synchronizes before" the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock "synchronizes before" that call to RLock, and the corresponding call to RUnlock "synchronizes before" the n+1'th call to Lock.
type ReadHeavyMap ¶
ReadHeavyMap is like a Go map[any]any but is safe for concurrent use by multiple goroutines without additional locking or coordination. Loads, stores, and deletes run in amortized constant time.
The Map type is specialized. Most code should use a plain Go map instead, with separate locking or coordination, for better type safety and to make it easier to maintain other invariants along with the map content.
The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.
The zero Map is empty and ready for use. A Map must not be copied after first use.
In the terminology of the Go memory model, Map arranges that a write operation “synchronizes before” any read operation that observes the effect of the write, where read and write operations are defined as follows. Load, LoadAndDelete, LoadOrStore, Swap, CompareAndSwap, and CompareAndDelete are read operations; Delete, LoadAndDelete, Store, and Swap are write operations; LoadOrStore is a write operation when it returns loaded set to false; CompareAndSwap is a write operation when it returns swapped set to true; and CompareAndDelete is a write operation when it returns deleted set to true.
type SingleFlightGroup ¶
type SingleFlightGroup[K comparable, V any] singleflight.Group[K, V]
SingleFlightGroup represents a class of work and forms a namespace in which units of work can be executed with duplicate suppression.
type WaitGroup ¶
A WaitGroup waits for a collection of goroutines to finish. The main goroutine calls Add to set the number of goroutines to wait for. Then each of the goroutines runs and calls Done when finished. At the same time, Wait can be used to block until all goroutines have finished.
A WaitGroup must not be copied after first use.
In the terminology of the Go memory model, a call to Done “synchronizes before” the return of any Wait call that it unblocks.
Source Files