Ask Your Question

Is there penalty for reference counting in Mat?

asked 2012-07-19 05:43:36 -0600

Michael Burdinov gravatar image

Recently I read Herb Sutter's paper Optimizations That Aren't (In a Multithreaded World) and discovered that reference counting (that should be an optimization) may cause huge performance loss if program is multithread-safe (even if it is running in single thread). That is exactly my situation: I write programs that run in single thread but they are part of complex multithreaded process.

So my questions are: Is Mat multithread safe? Is there penalty for reference counting? If yes, how big it is?

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2012-07-19 06:25:07 -0600

sammy gravatar image

updated 2012-07-19 06:49:54 -0600

cv::Mat and the generic cv::Ptr<> implement a classical refcount strategy, with atomic operations. They are regarded as very fast, especially because most processor implement in hardware all the operations needed for atomic increment/decrement. In most scenarios (if you do not run a 1000-threads app on a prototype CPU) the delay introduced by atomic operations can barely be measured.

Explanation: an atomic memory operation guarantees that there no other atomic operation is working with a given memory address. So, when you issue an atomic_increment, by example, the CPU will check in a special hardware register that the given address is not blocked by another atomic operation. All this is very fast, and the overload for address checking is low. The only problem would be when you actually have to wait for another instruction to finalize, but an increment in a modern processor takes a few cycles, and a mem write a few hundred cycles. That is not a lot.

Plus, given the fact that you most probably create/copy matrices rarely in your OpenCV app (dozens per sec, probably), both the chance to wait, and the waiting time are dwarfed by other processing.

If you make hundreds/thousands of Mat operations per sec (like mat1 = mat2, etc), then it may be a problem with your algorithm logic

About the safety, Mat & Ptr<> offer standard safety guarantees: They can be safely read or written in parallel (so multiple reads are safe, multiple writes are safe, but not mixed read/writes)


I've quickly checked the link you posted, and it seems that the author emphasizes the need to use refcounts over more heavyweight solutions (semaphores, critical sections, mutexes) - actually, refcounting is the fastest way to sync objects in a multithreaded environment

edit flag offensive delete link more


Thank you for the detailed explanation. It made things much clearer.

As for the article, author is not emphasizing the use of refcounts. Quite the opposite, he explains why refcounts in multithreaded enviroment could harm performance (unless they are using atomic operations). I just wanted to be sure that those problems were taken into account in Mat.

Michael Burdinov gravatar imageMichael Burdinov ( 2012-07-19 09:15:53 -0600 )edit

Welcome :) You should make the distinction between refcounts and other types of locks (which are slower). All sync mechanisms use atomic operations, it's just the way they are used that makes them more or less efficient.

sammy gravatar imagesammy ( 2012-07-19 15:02:36 -0600 )edit

Could you give some more details about safety? "They can be safely read or written in parallel (so multiple reads are safe, multiple writes are safe, but not mixed read/writes)" I understand that multiple reads are safe, but writes?

SR gravatar imageSR ( 2013-02-06 01:57:00 -0600 )edit

Question Tools

1 follower


Asked: 2012-07-19 05:43:36 -0600

Seen: 2,238 times

Last updated: Jul 19 '12