Add-Ons & Services

Timer.cpp::run() _perdiodicInterval - possible data race

Please post support and help requests here.

Timer.cpp::run() _perdiodicInterval - possible data race

Postby dpa » 03 Dec 2013, 01:41

libc defines in <signal.h> sig_atomic_t as a type, where data can be atomically stored and loaded (http://www.gnu.org/software/libc/manual ... Types.html). That said, the processor is not going to change the threads, while reading or writing a sig_atomic_t variable.

On my system, sizeof(sig_atomic_t) is 4 and sizeof(long) is 8.

In poco-1.4.6p2/Foundation/src/Timer.cpp at line 100, _periodicInterval is set to 0. and _periodicInterval is defined in Foundation/include/Poco/Timer.h as long. At line 100 writing to _periodicInterval is protected by ScopedLock(_mutex). Likewise in Timer::restart() at line 127, ::getPeriodicInterval, ::setPeriodicInternal...

but not in ::run() on line 211
interval = _periodicInterval;

At this place valgrind390 complains, that two threads can at the same time read and write to _periodicinterval. As writing to long { _periodicInterval} is not atomic, and the kernel can switch the threads during the writings, this line 211 must also be protected by ScopedLock(_mutex)
Posts: 6
Joined: 11 Aug 2013, 21:40

Re: Timer.cpp::run() _perdiodicInterval - possible data race

Postby dpa » 05 Dec 2013, 00:18

This fixes the problem:

Code: Select all
diff --git a/Foundation/src/Timer.cpp b/Foundation/src/Timer.cpp
index a72cb8b..778aef6 100644
--- a/Foundation/src/Timer.cpp
+++ b/Foundation/src/Timer.cpp
@@ -208,6 +208,7 @@ void Timer::run()
+                       FastMutex::ScopedLock lock(_mutex);
                        interval = _periodicInterval;
                _nextInvocation += static_cast<Timestamp::TimeVal>(interval)*1000;
Posts: 6
Joined: 11 Aug 2013, 21:40

Return to Support

Who is online

Users browsing this forum: No registered users and 5 guests