UMatData locks are not mapped on real locks (they are mapped to some "pre-initialized" pool). Concurrent execution of these statements may lead to deadlock: - a.copyTo(b) from thread 1 - c.copyTo(d) from thread 2 where: - 'a' and 'd' are mapped to single lock "A". - 'b' and 'c' are mapped to single lock "B". Workaround is to process locks with strict order.pull/10605/head
parent
ab8cf31ae9
commit
cec700525c
5 changed files with 78 additions and 15 deletions
@ -0,0 +1,20 @@ |
||||
// This file is part of OpenCV project.
|
||||
// It is subject to the license terms in the LICENSE file found in the top-level directory
|
||||
// of this distribution and at http://opencv.org/license.html.
|
||||
#ifndef OPENCV_CORE_SRC_UMATRIX_HPP |
||||
#define OPENCV_CORE_SRC_UMATRIX_HPP |
||||
|
||||
namespace cv { |
||||
|
||||
struct CV_EXPORTS UMatDataAutoLock |
||||
{ |
||||
explicit UMatDataAutoLock(UMatData* u); |
||||
UMatDataAutoLock(UMatData* u1, UMatData* u2); |
||||
~UMatDataAutoLock(); |
||||
UMatData* u1; |
||||
UMatData* u2; |
||||
}; |
||||
|
||||
} |
||||
|
||||
#endif // OPENCV_CORE_SRC_UMATRIX_HPP
|
Loading…
Reference in new issue