assignment copies lock value to

How should I avoid - literal copies lock value from

Kasun Vithanage

Dave Cheney

[email protected]

Understand GoLang WaitGroup internals and how it works

Before getting into the main content, let me give a brief introduction to WaitGroup and its related background knowledge. Here, the focus is on the basic usage of WaitGroup and the fundamental knowledge of system semaphores. For those who are familiar with these, you can skip this section directly.

WaitGroup is one of the most common concurrency control techniques in Golang, and its function can be roughly compared to the join() in concurrency control of other languages' multithreading. The sample code is as follows:

If there were no WaitGroup here, the main goroutine(main function) would directly run to the final "Main ends..." without the output of the two middle goroutines. With WaitGroup added, the main goroutine will block at wg.Wait() and wait for both goroutines to end before continuing execution.

The three methods of WaitGroup we saw above: Wait() , Add(int) , and Done() are also the only three methods of a WaitGroup struct.

Semaphore is a mechanism used to implement synchronization and mutual exclusion between multiple processes or threads, and it is also the technique used in WaitGroup. The synchronization principle of WaitGroup itself is also similar to that of Semaphore.

Semaphore can be essentially understood as an integer, mainly including two operations: P (Proberen, test) operation and V (Verhogen, increase) operation. The P operation will attempt to obtain a semaphore. If the value of the semaphore is greater than 0, the value of the semaphore will be reduced by 1 and the execution will continue. Otherwise, the current process or thread will be blocked until another process or thread releases this semaphore. The V operation releases a semaphore and increases its value by 1.

Semaphore can be thought of as something similar to a lock, where the P operation is equivalent to acquiring a lock, and the V operation is equivalent to releasing a lock. Since Semaphore is a mechanism at the operating system level, it is usually supported by the kernel. Therefore, we do not need to worry that the operations on Semaphore itself will produce race conditions. We believe that the kernel can handle this kind of thing.

The focus of this article is not on Semaphore, so we won't delve too much into the technical details of Semaphore. For those who are interested, you can refer to relevant materials.

Finally, let's talk about something other than technology. Proberen and Verhogen , these two words look unfamiliar, right? Because they are Dutch, not English. Why is it Dutch? Because the inventor of Semaphore was a computer pioneer from the Netherlands, the ancient computer master Edsger W. Dijkstra. Yes, that Dijkstra.

WaitGroup underlying logic

Disclaimer: The source code used in this article is based on Go version 1.20.3 . The WaitGroup source code for different versions of Go may differ slightly, but the design principles are generally consistent.

The relevant source code for WaitGroup is very short, with only about 120 lines including comments and blank lines. They are all in src/sync/waitgroup.go.

Let's first look at the definition of WaitGroup.

The WaitGroup type is a struct, which has three private members. Let's take a look at them one by one.

First is noCopy , which is used to tell the compiler that a WaitGroup struct object cannot be copied, i.e., wg2 := wg is illegal. The reason for prohibiting copying is to prevent possible deadlocks. However, in reality, if we copy a WaitGroup object, at least in version 1.20, Go's compiler only issues a warning and does not prevent the compilation process. We can still compile successfully. The warning message is as follows:

Why the compiler does not fail to compile, I guess it is because the Go official wants to minimize the intervention of the compiler in the program and leave more to the programmers to handle themselves (at this time Rust burst into laughter). In any case, when using WaitGroup, we should not try to copy it, otherwise it is very easy to cause deadlocks (in fact, the comments on the struct also say that WaitGroup cannot be copied after first use). For example, I slightly changed the main function in the code at the beginning of the article:

Why does this happen? Because wg has already been Add(1) , and at this point we copy wg to wg2 , and it is a shallow copy, meaning that wg2 internally is already in the state after Add(1) (the value stored in the state member). At this point, when we call wg2.Add(1) , we are actually executing wg2.Add(1) twice. Later, in waitFunc() , wg2 is only released once with Done() , and when main() calls wg2.Wait() , it gets stuck in an infinite wait, i.e., "all goroutines are asleep". After understanding the principles behind Add() and Done() later, when we look back at this deadlock code, it will become clearer.

So can we copy this code without causing a deadlock? Of course, we just need to move wg2 := wg in front of wg.Add(1) .

state atomic.Uint64

state is the core of WaitGroup. It is an unsigned 64-bit integer and uses Uint64 from the atomic package, so state itself is thread-safe. As for why atomic.Uint64 can ensure thread safety, it is because it uses the Compare And Swap (CAS) operation, which relies on atomic instructions provided by the CPU and is a CPU-level atomic operation.

The high 32 bits of state is the counter, and the low 32 bits is the number of waiters. The counter is actually the sum of the Add(int) quantities. For example, after Add(1) and Add(2) , the counter is 1 + 2 = 3. The number of waiters is the number of goroutines currently executing Wait() and waiting for WaitGroup to be released.

sema uint32

It is a semaphore, and we will talk about its usage later in the article with the help of some code examples.

Add(delta int)

All three methods of WaitGroup have no return value, and only Add has a parameter. The entire design is extremely concise.

The first line of code in the Add method is:

race.Enabled checks whether the program has enabled the detection of race conditions, which needs to be manually specified at compile time using

By default, it is not enabled, so race.Enabled is false by default. If the program has enabled the detection of race conditions, this code will disable it and then re-enable it later. We will not discuss other details related to race conditions in this article, as they have little effect on our understanding of the core mechanism of WaitGroup. Including them would only increase the complexity of our understanding of WaitGroup. Therefore, all parts related to race conditions will be ignored in the following code.

The code for the Add method after cleaning up is as follows:

At the beginning, the method converts the delta parameter to a uint64 , shifts it left by 32 bits, and adds it to state. Since the high 32 bits of state are the counter of this WaitGroup, this is actually an accumulation operation on the counter:

Next, the program extracts the accumulated counter v and the current number of waiters w :

Then there are several checks:

The comments are already quite clear. Here, let's explain the second if statement in more detail: if w != 0 && delta > 0 && v == int32(delta) .

• w != 0 means that there are goroutines waiting in Wait() ;
• delta > 0 means that Add() is called with a positive integer, i.e., a normal call;
• v == int32(delta) means that the accumulated counter is equal to the passed-in delta. The most straightforward scenario that satisfies this equation is when the original counter is 0, i.e., wg is used for the first time, or when all previous Wait() calls have already returned.

The above three conditions may seem somewhat conflicting: w != 0 indicates that there is a Wait() , while v == int32(delta) suggests that there is no Wait() . Further analysis reveals that v does not have a Wait() when it is obtained, while w has a Wait() when it is obtained. Is this possible? Yes! This can happen during concurrency: the current goroutine obtains v , and then another goroutine immediately calls Wait() . Then this goroutine obtains w again. The process is as follows:

We can use the following code to reproduce this panic:

This code may need to be run multiple times to see the above effect, as this concurrent operation can cause several types of panic during the entire lifecycle of the WaitGroup, including in the Wait() method.

Therefore, when using WaitGroup, we should be careful not to use Add inside the called goroutine, but outside, as follows:

This can avoid exceptions caused by concurrency.

After the three if statements, the consistency of state will be checked again to prevent concurrency exceptions:

Here, state.Load() and the Store() that will appear later are atomic operations of atomic.Uint64 .

According to the logic of the earlier code, the counter must be 0 when the program reaches this point, while the number of waiters may be >= 0. Therefore, the code will execute wg.state.Store(0) once to set state to 0, and then perform the operation of notifying the waiters to end their waiting:

Okay, this is another confusing part. When I first saw this code, I had several questions:

• Why does the Add method have a branch logic for a counter of 0? Isn't the counter cumulative?
• Why notify the waiters to end in Add instead of Done ?

Why does runtime_Semrelease(&wg.sema, false, 0) need to loop w times?

Let's take a closer look at each one.

Why does the Add method have a branch logic for a counter of 0?

First, according to the logic of the previous code, the code will only reach the last two sentences when the counter v is 0. The reason for being 0 is that the parameter delta of Add(delta int) is an int, which means delta can be negative! So when will a negative number be passed in? At the time of Done. If we look at the code for Done(), we can see that it is very simple:

Therefore, when we use Done() or manually pass a negative number to Add, we will enter the last few lines of Add's logic. Done itself also means the end of the current goroutine's WaitGroup, and needs to be synchronized with the external Wait to unblock it.

Why do we notify the waiters to end in Add instead of Done method?

Well, this question was actually solved together in the previous question, because Done() actually calls Add(-1).

This function, as its literal meaning suggests, releases a semaphore. The source code is located in src/sync/runtime.go , and the function declaration is as follows:

The first parameter is the value of the semaphore itself, and it will be increased by 1 when it is released.

The second parameter handoff, based on my understanding after consulting materials, should be: When handoff is false, only other waiting coroutines are awakened normally, but the awakened coroutines will not be immediately scheduled; when handoff is true, the awakened coroutines will be scheduled immediately.

The third parameter skipframes seems to be related to scheduling, but I'm not sure about the specific meaning, so I won't guess here (sorry for my limited knowledge).

According to the mechanism of the semaphore itself, the value of the semaphore will be increased by 1 when it is released. Similarly, there is a semaphore acquisition function runtime_Semacquire(s *uint32) which will decrease the semaphore by 1 when the semaphore > 0, otherwise it will wait. It will be called in Wait(). This is also the reason why runtime_Semrelease needs to loop w times: because there will be w Wait() calls that will call runtime_Semacquire and decrease the semaphore by 1, so the two places need to offset each other.

The mechanism of the semaphore is similar to that of WaitGroup, but the counter is reversed, so here are a few more words to supplement:

When the semaphore is acquired (runtime_Semacquire), it is actually blocking and waiting, doing a P (Proberen, test) operation. If the semaphore > 0 at this time, the acquisition is successful, and the semaphore is decreased by 1, otherwise it continues to wait.

When the semaphore is released (runtime_Semrelease), the semaphore will be increased by 1, which is a V (Verhogen, increase) operation.

We have seen Done() explained above.

Below is the cleaned up code for Wait() with race condition related code removed.

Compared to Add , Wait is much simpler, and with the lengthy explanation of Add as a basis, the code for Wait seems clear at a glance.

When the counter is 0, that is, when no goroutine calls Add, calling Wait directly has no meaning, so it returns directly without operating on the semaphore.

Finally, Wait also has a check to prevent concurrency issues, and this panic can also be reproduced using the concurrency issue code in Add, which you can try.

The only difference in Wait is that it uses an infinite loop for{}, why? This is because the atomic operation wg.state.CompareAndSwap(state, state+1) may fail due to concurrency reasons, so it is necessary to reacquire state and go through the whole process again. Once the operation is successful, Wait will block at runtime_Semacquire(&wg.sema) until the Done operation reduces the counter to 0, and Add releases the semaphore.

The source code for WaitGroup has been fully analyzed. As one of the most important concurrency components in Golang, the source code for WaitGroup is surprisingly only a few dozen lines of code, which makes it much easier for us to understand its internals.

Reference:  Golang WaitGroup 底层原理及源码详解 - 程序员小屋 - SegmentFault 思否

SOURCE CODE   GOLANG   WAITGROUP  

  RELATED

• Different ways of handling concurrent job in GoLang
• errGroup in GoLang explained
• How to check whether a struct implements an interface in GoLang
• Why no max/min function for integer in GoLang
• Fix --go_out: protoc-gen-go: plugins are not supported
• What is the use of empty struct in GoLang
• Implement struct no copy in GoLang
• How to organize a successful technical party?
• Time to think about supporting max/min functions for integers in GoLang
• Be careful about printing error as string in GoLang

   0 COMMENT

No comment for this article.

• Privacy policy
• Terms of service

HOW IT WORKS

• Article guideline
• Topic guideline
• Submit article
•   RSS
•   Weibo
•   Facebook
•   Twitter

This package is not in the latest version of its module.

Documentation ¶

Package pragma provides types that can be embedded into a struct to statically enforce or prevent certain language properties. The key observation and some code (shr) is borrowed from https://github.com/protocolbuffers/protobuf-go/blob/v1.25.0/internal/pragma/pragma.go

• type CopyChecker
• func (c *CopyChecker) Check()
• func (c *CopyChecker) Copied() bool
• type DoNotCompare
• type DoNotCopy
• type DoNotImplement
• type NoUnkeyedLiterals
• CopyChecker
• DoNotCompare
• DoNotImplement
• NoUnkeyedLiterals

Constants ¶

This section is empty.

Variables ¶

Functions ¶, type copychecker ¶.

CopyChecker holds back pointer to itself to detect object copying. Deprecated. use DoNotCopy instead, check by go vet. methods Copied or Check return not copied if none of methods Copied or Check have bee called before

func (*CopyChecker) Check ¶

Check panic is c is copied

func (*CopyChecker) Copied ¶

Copied returns true if this object is copied

type DoNotCompare ¶

DoNotCompare can be embedded in a struct to prevent comparability.

type DoNotCopy ¶

DoNotCopy can be embedded in a struct to help prevent shallow copies. This does not rely on a Go language feature, but rather a special case within the vet checker.

See https://golang.org/issues/8005 .

type DoNotImplement ¶

Type nounkeyedliterals ¶.

NoUnkeyedLiterals can be embedded in a struct to prevent unkeyed literals.

Source Files ¶

Keyboard shortcuts.

Schoolwork User Guide

• Manage classes, teachers, and students
• What is Schoolwork?
• Schoolwork requirements
• Request a teacher account
• About classes, assignments, and students
• About class files and iCloud Drive
• Add, edit, remove, and delete classes
• Create and manage student accounts
• About assignments
• Create assignments
• Schedule assignments
• View assignments
• Edit assignments
• Keep track of assignments
• Copy, share, and lock assignments
• Complete and delete assignments
• Export assignments
• About activities
• Save bookmark activities
• Add activities
• View activities
• Reorder and delete activities
• About progress
• About activities and progress data
• View class, assignment, and student progress
• Filter progress data
• View students with progress reporting turned off
• About exit ticket results
• View exit ticket results
• View exit ticket student data
• Create assignments from exit ticket results
• Copy student names from exit ticket results
• About insights
• View class, assignment, and student insights
• Review work
• Manage activities
• Collaborate with students
• Contact your students
• Symbols used in Schoolwork
• Get support
• Troubleshooting

Copy, share, and lock assignments in Schoolwork

After you create an assignment , you can copy the assignment to use it again later, or use it in another class. You can also copy the link for a published assignment to share the assignment outside of Schoolwork.

When you want to pause work on an assignment, you can lock the assignment. If you need to use an assignment after you lock it, you can unlock the assignment.

Copy an assignment

When copying an assignment, Schoolwork creates a new assignment using the activities and work from the original assignment. Schoolwork does not copy over any assignment recipients.

Important: Imported assignments are not visible to students and co-teachers until you create a copy, add recipients, and publish the assignments.

Do one of the following:

Touch and hold the assignment you want to copy, then tap Create a Copy.

Edit the copy, then do one of the following:

If you’re ready to publish your assignment, tap Publish.

If you specified a delivery date, tap Schedule. Schoolwork saves the assignment in the Scheduled tab to send on the specified date and time.

If you aren’t ready to publish or schedule your assignment, tap Cancel, then tap Save as Draft to save it as a draft to send at a later time.

Share an assignment link

You can copy the link for a published assignment to share the assignment with your students and other teachers outside of Schoolwork.

Touch and hold the assignment you want to share, tap Share Link, then tap Copy.

Schoolwork copies the assignment link to your Clipboard.

To view and share the assignment, paste the assignment link into a message or email that students or teachers can access on their iPadOS device.

To view the assignment, any students or teachers you share the assignment with must be in the same class and included on the assignment distribution list.

Note: To share an assignment with other teachers who use Schoolwork or other learning tools that support importing a Common Cartridge file, export the assignment .

Lock an assignment

When you want to pause work on an assignment, you can lock it. When you lock an assignment, progress isn’t reported and students can’t make changes to any activities associated with the assignment (for example, submit and replace work, collaborate on assignment activities, or mark an activity as done ). When you view a locked assignment, you can see all progress data up until the locked date.

After you lock an assignment, if you want to give an individual student more time to complete a specific activity in the assignment, you can tap Allow to Complete to unlock an activity for a student .

Touch and hold the assignment you want to lock, then tap Lock.

Note: It’s easy to unlock an assignment — just touch and hold a locked assignment, then tap Unlock.

An official website of the United States government

Here's how you know

Official websites use .gov A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS A lock ( Lock Locked padlock icon ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

2024 United States Mint American Eagle Gold Proof Coins on Sale May 2

WASHINGTON – The United States Mint (Mint) announces the opening of sales for the 2024 American Eagle Gold Proof Coins on May 2 at noon EDT. Orders are limited to three items per product code per household for the first 24 hours from the on-sale date and time.

Struck in 22-karat gold at the United States Mint facility at West Point, these popular coins are collector versions of the official United States Mint American Eagle Gold Bullion Coins. In 2021, for the first time since their introduction more than three decades before, the reverse (tails) of American Eagle Gold Proof Coins debuted a newly designed portrayal of an eagle, created by United States Mint Artistic Infusion Program Designer Jennie Norris and sculpted by United States Mint Medallic Artist Renata Gordon. Inscriptions are “UNITED STATES OF AMERICA,” “E PLURIBUS UNUM,” and “IN GOD WE TRUST,” along with the face value and weight.

The coins’ obverse (heads) features Augustus Saint-Gaudens’ full-length figure of Liberty with flowing hair, holding a torch in her right hand and an olive branch in her left. To render a closer reflection of Saint-Gaudens’ original vision, legacy details of the obverse design also were restored in 2021, including modifications to the U.S. Capitol Building, stars, torch, sun rays, and other design elements based on the original bronze cast.

In addition to redesigning the reverse and enhancing design details on the obverse of these coins in 2021, the Mint introduced anti-counterfeiting features that include a reeded edge variation on the one ounce coin.

The 2024 American Eagle Gold Proof Coins will be available in the following five product options:

*The product limit is the total available for each individual product.

**The mintage limit represents the total number of coins produced for this denomination, including those contained in the American Eagle Gold Proof Four-Coin Set.

The individual coins are encapsulated, packaged in a black presentation case, and housed in a box with the United States Mint seal on the lid. The box fits into an outer sleeve with a beautiful gold foil image of Liberty. Coins and sets are accompanied by a certificate of authenticity with matching imagery.

American Eagle Gold Proof Coins are priced according to the range in which they appear on the Mint’s Pricing of Numismatic Gold, Commemorative Gold, and Platinum and Palladium Products table. Current pricing information is available here . These prices may be updated on a weekly basis on Wednesdays, based on the precious metals market. A detailed explanation about the Mint’s pricing strategy is available at https://catalog.usmint.gov/faqs-faqcategory-products-programs/payment-processing-charges-pricing.html .

To sign up for REMIND ME alerts, visit:

• https://catalog.usmint.gov/american-eagle-2024-one-ounce-gold-proof-coin-24EB.html (product code 24EB)
• https://catalog.usmint.gov/american-eagle-2024-one-half-ounce-gold-proof-coin-24EC.html (product code 24EC)
• https://catalog.usmint.gov/american-eagle-2024-one-quarter-ounce-gold-proof-coin-24ED.html (product code 24ED)
• https://catalog.usmint.gov/american-eagle-2024-one-tenth-ounce-gold-proof-coin-24EE.html (product code 24EE)
• https://catalog.usmint.gov/american-eagle-2024-gold-proof-four-coin-set-24EF.html (product code 24EF)

The American Eagle Gold Proof One Ounce Coin, One-Tenth Ounce Coin and Four-Coin Set are included in the Authorized Bulk Purchase Program (ABPP) and are available to Authorized Bulk members. Products listed in this program will be eligible for early release, carry an AB suffix in the product code, and may carry a premium. Early released products are not eligible for discounts.

About the United States Mint Congress created the United States Mint in 1792, and the Mint became part of the Department of the Treasury in 1873. As the Nation’s sole manufacturer of legal tender coinage, the Mint is responsible for producing circulating coinage for the Nation to conduct its trade and commerce. The Mint also produces numismatic products, including proof, uncirculated, and commemorative coins; Congressional Gold Medals; silver and bronze medals; and silver and gold bullion coins. Its numismatic programs are self-sustaining and operate at no cost to taxpayers.

Note: To ensure that all members of the public have fair and equal access to United States Mint products, the United States Mint will not accept and will not honor orders placed prior to the official on-sale date of May 2,2024, at noon EDT.

• Visit https://www.usmint.gov/about for information about the United States Mint.
• Watch our flagship video honoring the American Eagle Coin Program: https://www.youtube.com/watch?v=rs6_FTgIX8Y
• Visit https://catalog.usmint.gov/email-signup to subscribe to United States Mint electronic product notifications, news releases, public statements, and our monthly educational newsletter, Lessons That Make Cents .
• Sign up for RSS Feeds from the United States Mint and follow us on Facebook , Twitter , and Instagram .

United States Mint – Connecting America through Coins

A list of linkable tags for topics mentioned on this page.

• American Eagle
• Press Release
• Privacy Policy
• Terms of Use
• Accessibility

© United States Mint All Rights Reserved.