package sync

Import Path
	sync (on go.dev)

Dependency Relation
	imports 4 packages, and imported by 26 packages


Involved Source Files

	      cond.go
	      map.go
	
		Package sync provides basic synchronization primitives such as mutual
		exclusion locks. Other than the Once and WaitGroup types, most are intended
		for use by low-level library routines. Higher-level synchronization is
		better done via channels and communication.

		Values containing the types defined in this package should not be copied.

	      once.go
	      pool.go
	      poolqueue.go
	      runtime.go
	      runtime2.go
	      rwmutex.go
	      waitgroup.go


Code Examples

	
		package main
		
		import (
			"fmt"
			"sync"
		)
		
		func main() {
			var once sync.Once
			onceBody := func() {
				fmt.Println("Only once")
			}
			done := make(chan bool)
			for i := 0; i < 10; i++ {
				go func() {
					once.Do(onceBody)
					done <- true
				}()
			}
			for i := 0; i < 10; i++ {
				<-done
			}
		}

	
		package main
		
		import (
			"bytes"
			"io"
			"os"
			"sync"
			"time"
		)
		
		var bufPool = sync.Pool{
			New: func() interface{} {
				// The Pool's New function should generally only return pointer
				// types, since a pointer can be put into the return interface
				// value without an allocation:
				return new(bytes.Buffer)
			},
		}
		
		// timeNow is a fake version of time.Now for tests.
		func timeNow() time.Time {
			return time.Unix(1136214245, 0)
		}
		
		func Log(w io.Writer, key, val string) {
			b := bufPool.Get().(*bytes.Buffer)
			b.Reset()
			// Replace this with time.Now() in a real logger.
			b.WriteString(timeNow().UTC().Format(time.RFC3339))
			b.WriteByte(' ')
			b.WriteString(key)
			b.WriteByte('=')
			b.WriteString(val)
			w.Write(b.Bytes())
			bufPool.Put(b)
		}
		
		func main() {
			Log(os.Stdout, "path", "/search?q=flowers")
		}

	
		package main
		
		import (
			"sync"
		)
		
		type httpPkg struct{}
		
		func (httpPkg) Get(url string) {}
		
		var http httpPkg
		
		func main() {
			var wg sync.WaitGroup
			var urls = []string{
				"http://www.golang.org/",
				"http://www.google.com/",
				"http://www.somestupidname.com/",
			}
			for _, url := range urls {
				// Increment the WaitGroup counter.
				wg.Add(1)
				// Launch a goroutine to fetch the URL.
				go func(url string) {
					// Decrement the counter when the goroutine completes.
					defer wg.Done()
					// Fetch the URL.
					http.Get(url)
				}(url)
			}
			// Wait for all HTTP fetches to complete.
			wg.Wait()
		}




Package-Level Type Names (total 21, in which 8 are exported)


	/* sort exporteds by:  |  */
	
		Cond implements a condition variable, a rendezvous point
		for goroutines waiting for or announcing the occurrence
		of an event.

		Each Cond has an associated Locker L (often a *Mutex or *RWMutex),
		which must be held when changing the condition and
		when calling the Wait method.

		A Cond must not be copied after first use.

		
			
				L is held while observing or changing the condition

			
		
			
				Broadcast wakes all goroutines waiting on c.

				It is allowed but not required for the caller to hold c.L
				during the call.

			
				Signal wakes one goroutine waiting on c, if there is any.

				It is allowed but not required for the caller to hold c.L
				during the call.

			
				Wait atomically unlocks c.L and suspends execution
				of the calling goroutine. After later resuming execution,
				Wait locks c.L before returning. Unlike in other systems,
				Wait cannot return unless awoken by Broadcast or Signal.

				Because c.L is not locked when Wait first resumes, the caller
				typically cannot assume that the condition is true when
				Wait returns. Instead, the caller should Wait in a loop:

				   c.L.Lock()
				   for !condition() {
				       c.Wait()
				   }
				   ... make use of condition ...
				   c.L.Unlock()

		
			func NewCond(l Locker) *Cond


	
		A Locker represents an object that can be locked and unlocked.

		
			( T) Lock()
			( T) Unlock()
		
			*Mutex
			*RWMutex
			
		
			func (*RWMutex).RLocker() Locker
		
			func NewCond(l Locker) *Cond


	
		Map is like a Go map[interface{}]interface{} 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.

		
			
		
			
				Delete deletes the value for a key.

			
				Load returns the value stored in the map for a key, or nil if no
				value is present.
				The ok result indicates whether value was found in the map.

			
				LoadAndDelete deletes the value for a key, returning the previous value if any.
				The loaded result reports whether the key was present.

			
				LoadOrStore returns the existing value for the key if present.
				Otherwise, it stores and returns the given value.
				The loaded result is true if the value was loaded, false if stored.

			
				Range calls f sequentially for each key and value present in the map.
				If f returns false, range stops the iteration.

				Range does not necessarily correspond to any consistent snapshot of the Map's
				contents: no key will be visited more than once, but if the value for any key
				is stored or deleted concurrently, Range may reflect any mapping for that key
				from any point during the Range call.

				Range may be O(N) with the number of elements in the map even if f returns
				false after a constant number of calls.

			
				Store sets the value for a key.

			
		
			


	
		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.

		
			
		
			
				Lock locks m.
				If the lock is already in use, the calling goroutine
				blocks until the mutex is available.

			
				Unlock unlocks m.
				It is a run-time error if m is not locked on entry to Unlock.

				A locked Mutex is not associated with a particular goroutine.
				It is allowed for one goroutine to lock a Mutex and then
				arrange for another goroutine to unlock it.

			
		
			*T : Locker
		
			


	
		Once is an object that will perform exactly one action.

		A Once must not be copied after first use.

		
			
		
			
				Do calls the function f if and only if Do is being called for the
				first time for this instance of Once. In other words, given
					var once Once
				if once.Do(f) is called multiple times, only the first call will invoke f,
				even if f has a different value in each invocation. A new instance of
				Once is required for each function to execute.

				Do is intended for initialization that must be run exactly once. Since f
				is niladic, it may be necessary to use a function literal to capture the
				arguments to a function to be invoked by Do:
					config.once.Do(func() { config.init(filename) })

				Because no call to Do returns until the one call to f returns, if f causes
				Do to be called, it will deadlock.

				If f panics, Do considers it to have returned; future calls of Do return
				without calling f.

			
		
			


	
		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.

		
			
				New optionally specifies a function to generate
				a value when Get would otherwise return nil.
				It may not be changed concurrently with calls to Get.

			
		
			
				Get selects an arbitrary item from the Pool, removes it from the
				Pool, and returns it to the caller.
				Get may choose to ignore the pool and treat it as empty.
				Callers should not assume any relation between values passed to Put and
				the values returned by Get.

				If Get would otherwise return nil and p.New is non-nil, Get returns
				the result of calling p.New.

			
				Put adds x to the pool.

			
		
			
		
			


	
		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 a goroutine holds a RWMutex for reading and another goroutine might
		call Lock, no goroutine should expect to be able to acquire a read lock
		until the initial read lock is released. In particular, this prohibits
		recursive read locking. This is to ensure that the lock eventually becomes
		available; a blocked Lock call excludes new readers from acquiring the
		lock.

		
			
		
			
				Lock locks rw for writing.
				If the lock is already locked for reading or writing,
				Lock blocks until the lock is available.

			
				RLock locks rw for reading.

				It should not be used for recursive read locking; a blocked Lock
				call excludes new readers from acquiring the lock. See the
				documentation on the RWMutex type.

			
				RLocker returns a Locker interface that implements
				the Lock and Unlock methods by calling rw.RLock and rw.RUnlock.

			
				RUnlock undoes a single RLock call;
				it does not affect other simultaneous readers.
				It is a run-time error if rw is not locked for reading
				on entry to RUnlock.

			
				Unlock unlocks rw for writing. It is a run-time error if rw is
				not locked for writing on entry to Unlock.

				As with Mutexes, a locked RWMutex is not associated with a particular
				goroutine. One goroutine may RLock (Lock) a RWMutex and then
				arrange for another goroutine to RUnlock (Unlock) it.

			
		
			*T : Locker
		
			  var syscall.ForkLock
			


	
		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.

		
			
		
			
				Add adds delta, which may be negative, to the WaitGroup counter.
				If the counter becomes zero, all goroutines blocked on Wait are released.
				If the counter goes negative, Add panics.

				Note that calls with a positive delta that occur when the counter is zero
				must happen before a Wait. Calls with a negative delta, or calls with a
				positive delta that start when the counter is greater than zero, may happen
				at any time.
				Typically this means the calls to Add should execute before the statement
				creating the goroutine or other event to be waited for.
				If a WaitGroup is reused to wait for several independent sets of events,
				new Add calls must happen after all previous Wait calls have returned.
				See the WaitGroup example.

			
				Done decrements the WaitGroup counter by one.

			
				Wait blocks until the WaitGroup counter is zero.

			
		
			


	


Package-Level Functions (total 27, in which 1 are exported)


	
		NewCond returns a new Cond with Locker l.


	


Package-Level Variables (total 5, none are exported)

	


Package-Level Constants (total 8, none are exported)