added mutex at right places

[ashutosji]

What type of PR is this?

Uncomment only one /kind <> line, press enter to put that in a new line, and remove leading whitespace from that line:

/kind breaking
/kind bug
/kind cleanup
/kind documentation
/kind feature
/kind hotfix
/kind release

What this PR does / Why we need it: This PR will resolve concurrent map writes issue.

Which issue(s) this PR fixes: #3670

Closes #3670

Special notes for your reviewer:

[agones-bot]

Build Succeeded 👏

Build Id: 33c440c1-ecf6-4c03-b214-284132e8ae80

The following development artifacts have been built, and will exist for the next 30 days:

• image: us-docker.pkg.dev/agones-images/ci/agones-controller:1.39.0-dev-646a1af-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-extensions:1.39.0-dev-646a1af-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-sdk:1.39.0-dev-646a1af-linux-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-ping:1.39.0-dev-646a1af-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-allocator:1.39.0-dev-646a1af-amd64
• Linux C++ SDK (build): agonessdk-1.39.0-dev-646a1af-amd64-linux-arch_64.tar.gz
• SDK Server: agonessdk-server-1.39.0-dev-646a1af-amd64.zip

A preview of the website (the last 30 builds are retained):

• https://646a1af-dot-preview-dot-agones-images.appspot.com/

To install this version:

• git fetch https://github.com/googleforgames/agones.git pull/3678/head:pr_3678 && git checkout pr_3678
• helm install agones ./install/helm/agones --namespace agones-system --set agones.image.registry=us-docker.pkg.dev/agones-images/ci --set agones.image.tag=1.39.0-dev-646a1af-amd64

[markmandel]

Do we need to have similar locking here:

agones/test/load/allocation/runscenario/runscenario.go

Line 133 in 646a1af

allocCnts[clientID]++

Looks like allocCnts has the same issue.

When we get to

agones/test/load/allocation/runscenario/runscenario.go

Lines 146 to 152 in 646a1af

	for j := 0; j < sc.numOfClients; j++ {
	scnAllocCnt += allocCnts[j]
	scnFailureCnt += failureCnts[j]
	for k, v := range failureDtls[j] {
	totalFailureDtls[k] += v
	scnErrDtls[k] += v
	}

Also wondering if that should be locked?

[ashutosji]

Do we need to have similar locking here:

agones/test/load/allocation/runscenario/runscenario.go

Line 133 in 646a1af

allocCnts[clientID]++

Looks like allocCnts has the same issue.

Yes, We can have the mutex here.

When we get to

agones/test/load/allocation/runscenario/runscenario.go

Lines 146 to 152 in 646a1af

	for j := 0; j < sc.numOfClients; j++ {
	scnAllocCnt += allocCnts[j]
	scnFailureCnt += failureCnts[j]
	for k, v := range failureDtls[j] {
	totalFailureDtls[k] += v
	scnErrDtls[k] += v
	}

Also wondering if that should be locked?

Ratio of error is very less here. We can have it without mutex, But, However rather than using mutiple mutex i though of utilizing atomic since we are having WaitGroup in place.
WDYT?

[agones-bot]

Build Succeeded 👏

Build Id: eb14ceab-8970-44cb-b97d-f10e6cb58357

The following development artifacts have been built, and will exist for the next 30 days:

• image: us-docker.pkg.dev/agones-images/ci/agones-controller:1.39.0-dev-2e83d24-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-extensions:1.39.0-dev-2e83d24-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-sdk:1.39.0-dev-2e83d24-linux-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-ping:1.39.0-dev-2e83d24-amd64
• image: us-docker.pkg.dev/agones-images/ci/agones-allocator:1.39.0-dev-2e83d24-amd64
• Linux C++ SDK (build): agonessdk-1.39.0-dev-2e83d24-amd64-linux-arch_64.tar.gz
• SDK Server: agonessdk-server-1.39.0-dev-2e83d24-amd64.zip

A preview of the website (the last 30 builds are retained):

• https://2e83d24-dot-preview-dot-agones-images.appspot.com/

To install this version:

• git fetch https://github.com/googleforgames/agones.git pull/3678/head:pr_3678 && git checkout pr_3678
• helm install agones ./install/helm/agones --namespace agones-system --set agones.image.registry=us-docker.pkg.dev/agones-images/ci --set agones.image.tag=1.39.0-dev-2e83d24-amd64

[markmandel]

Ratio of error is very less here. We can have it without mutex, But, However rather than using mutiple mutex i though of utilizing atomic since we are having WaitGroup in place.

Clever! I like it.