[CPU] fix wrong result in ScatterNDUpadte when there are conflict indices

[tiger100256-hu]

Details:

• when there are conflict indices, the last should be valid, but in the CPU plugin, the ScatterNDUpadte operation is done in multi thread by tbb, so it can't be sure the operation is done according to the indices order

Tickets:

• CVS-170348

[Copilot]

Pull Request Overview

This PR fixes a thread safety issue in the ScatterNDUpdate operation in the Intel CPU plugin where conflicting indices could produce incorrect results due to multi-threaded execution. The fix ensures that when multiple indices point to the same location, only the last update operation is applied, maintaining the expected behavior.

• Introduces mutex-based synchronization to handle conflicting indices in multi-threaded execution
• Adds tracking of the last valid update index to ensure correct ordering
• Includes a new test case with conflicting indices to verify the fix

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
scatter_update.cpp	Implements mutex-based synchronization and index tracking to handle conflicting indices correctly
scatter_ND_update.cpp	Adds test case with conflicting indices to validate the fix

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}

[Copilot]

Creating a vector of mutexes equal to the number of slices may cause performance degradation and excessive memory usage for large tensors. Consider using a smaller pool of mutexes with a hash-based mapping to reduce overhead.

Suggested change

	std::vector<std::mutex> mutexVec(srcBlockND[0] / srcBlockND[k]);
	constexpr size_t NUM_MUTEXES = 1024; // or 256, tune as needed
	std::vector<std::mutex> mutexVec(NUM_MUTEXES);

[Copilot]

Using manual mutex lock/unlock is error-prone and can lead to deadlocks if an exception occurs between lock and unlock. Use std::lock_guard or std::unique_lock for RAII-based exception-safe locking.

Suggested change

	mutexVec[sliceIdx].unlock();
	std::lock_guard<std::mutex> lock(mutexVec[sliceIdx]);
	if (static_cast<int64_t>(tupleIdx) > updatedIdxVec[sliceIdx]) {
	cpu_memcpy(dstData + dstOffset, update + updateOffset, sizeToUpdate);
	updatedIdxVec[sliceIdx] = tupleIdx;
	}

[Copilot]

Manual unlock should be replaced with RAII-based locking (std::lock_guard) to ensure the mutex is properly unlocked even if an exception occurs.

Suggested change

	mutexVec[sliceIdx].unlock();
	{
	std::lock_guard<std::mutex> lock(mutexVec[sliceIdx]);
	if (static_cast<int64_t>(tupleIdx) > updatedIdxVec[sliceIdx]) {
	cpu_memcpy(dstData + dstOffset, update + updateOffset, sizeToUpdate);
	updatedIdxVec[sliceIdx] = tupleIdx;
	}
	}

[liubo-intel]

Hi, @tiger100256-hu : thanks for root cause this puzzling CI testcase issue. and the method implemented in this pr looks like could solve this kind of CI failure phenomenon.
But from the spec of this 'ScatterNDUpdate' operator, it seems this kind of output various is expected. so maybe we just need to change the failed CI testcase to use Non-conflicting Indices?(and from my understanding, add mutex in the operator implement may affect its inference performance)

[tiger100256-hu]

@liubo-intel thanks very much, I forget to see this spec. from the spec, openvino ScatterNDUpdate don't support conflict indices so, the convert maybe is not right here

openvino/src/frontends/paddle/src/op/scatter.cpp

Line 27 in 2080c1a

if (overwrite) {

, I will check the paddle frontend code and find a way to fix this issue.

[tiger100256-hu]

close this pr, it 's not a correct way to fix this issue.