Conversation
| int hr = hrange; | ||
| const int* hdiv_table = hr == 180 ? hdiv_table180 : hdiv_table256; | ||
|
|
||
| cv::AutoLock lock(*mutex); |
There was a problem hiding this comment.
This change is not valid as it serializes parallel code.
There is more generic problem related to TSAN. It expects std::atomic usage - OpenCV codebase is still not ported to them (atomics is C++11 feature).
Solution should be complete - otherwise problem is not resolved.
There was a problem hiding this comment.
I fixed the serialization. For TSAN and atomic, I can also only submit this patch to 4.x.
I indeed believe there are other TSAN issues with 3.x that are unfixable anyway.
There was a problem hiding this comment.
In general there is no bug if multiple threads writes sdiv_table/hdiv_table180/hdiv_table256 tables values in parallel (result is be the same anyway).
As stated in PRs description, the problem is related to initialized load/store.
Also there is no reason to initialize tables in workers if they use the same data. Moved initialization to constructor.
Proposed patch:
alalek@pr21948_r
/cc @vpisarev
There was a problem hiding this comment.
Thx, of course, that is the proper fix. Thx ! Closing this
| CvtColorLoop(src_data, src_step, dst_data, dst_step, width, height, RGB2HSV_b(scn, blueIdx, hrange)); | ||
| else | ||
| if(depth == CV_8U) { | ||
| Mutex cvtColorLockInstance; |
There was a problem hiding this comment.
Using different mutexes from multiple threads doesn't help to avoid initialization data race (because they are different)
initializedcan be read while the if condition is not done yet andinitializedupdated.Pull Request Readiness Checklist