Skip to content

fixed ocl.cpp data races without requiring additional locking #27638

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: 4.x
Choose a base branch
from

Conversation

kallaballa
Copy link
Contributor

See: #27637

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

  • I agree to contribute to the project under Apache 2 License.
  • To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
  • The PR is proposed to the proper branch
  • There is a reference to the original bug report and related work
  • There is accuracy test, performance test and test data in opencv_extra repository, if applicable
    Patch to opencv_extra has the same branch name.
  • The feature is well documented and sample code can be built with the project CMake

@kallaballa kallaballa mentioned this pull request Aug 6, 2025
4 tasks
@kallaballa
Copy link
Contributor Author

not ready for review

@asmorkalov
Copy link
Contributor

@opencv-alalek could you take a look?

@kallaballa kallaballa force-pushed the data_races_in_ocl_cpp branch from 882cbc5 to dc0bfd0 Compare August 7, 2025 07:16
@kallaballa
Copy link
Contributor Author

Improved, ready for review.

@asmorkalov asmorkalov added this to the 4.13.0 milestone Aug 7, 2025
Copy link
Contributor

@opencv-alalek opencv-alalek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no real data race issues.
You need to provide workarounds for TSAN instead.

@@ -6602,17 +6599,16 @@ class OpenCLAllocator CV_FINAL : public MatAllocator

void flushCleanupQueue() const
{
if (!cleanupQueue.empty())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forcing mutex usage is a performance degradation.

@@ -3500,7 +3500,7 @@ struct Kernel::Impl

void addUMat(const UMat& m, bool dst)
{
CV_Assert(nu < MAX_ARRS && m.u && m.u->urefcount > 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not drop sanity checks.

We don't need exact values of refcount, we just check that object is still alive (any value > 0).

@@ -5670,9 +5670,6 @@ class OpenCLAllocator CV_FINAL : public MatAllocator
if(!u)
return;

CV_Assert(u->urefcount == 0);
CV_Assert(u->refcount == 0 && "UMat deallocation error: some derived Mat is still alive");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not drop sanity checks.

We don't need exact values of refcount, we just check that object is still alive (any value > 0) or not.

@kallaballa
Copy link
Contributor Author

Ok, i understand. i will write source comments for those false positives so others can quickly discard them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants