Project: webrtc Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 1572 Windows bug in webrtc/system_wrappers/interface/tick_util.h
Starred by 8 users Reported by, Apr 3 2013 Back to list
Status: Untriaged
Owner: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment
What steps will reproduce the problem?

In tick_util.h has following code;

 (C1) DWORD now = timeGetTime();                                      
 (C2) DWORD old = InterlockedExchange(lastTimeGetTimePtr, now);
 (C3) if ((now < old) && (old > 0xf0000000 && now < 0x0fffffff)) { numWrapTimeGetTime++; }
 (C4) result = now + (numWrapTimeGetTime<<32);

 Thread Sequence (now/old)

 Thread 1     Thread 2      Thread 3       Last       Wrap
 (C1) 99/                                   90         0
 Context Switch
              (C1) 2/
              (C2) 2/90                      2         
              (C3) Yes                                 1
              (C4) result:102
 (C2) 99/2                                  99
 (C3) no
 (C4) result:199 (BUG!)
                            (C1) 5/
                            (C2) 5/99        5
                            (C3) Yes                   2
                            (C4) result:205 (BUG!)

What is the expected result?

  Correct absolute timestamp returned

What do you see instead?

  Incorrect timestamp

What version of the product are you using? On what operating system?
Project Member Comment 1 by, Apr 8 2013
@Patrick, could you please help to take a look at this?
Project Member Comment 2 by, Apr 9 2013
Status: Assigned
Comment 3 by, Apr 11 2013
Labels: -Pri-2 Pri-3
I agree with the assessment that this code is not thread safe during wraparound.

The simple way of fixing this would be to acquire a lock but doing so would likely cause a performance hit so we don't want to do that.

Trying to fix this in a lock free way is risky as it is very likely to introduce subtle issues.

The likelihood of this happening is very small. On average a wraparound happens every ~49.7/2 days. In addition, at the time of wraparound a thread that was about to increment the wraparound counter must have been preempted by another thread beating it to the punch for there to be a data race.

If a very incorrect timestamp is generated e.g. to mark the capture time of a frame it would be caught by sanity checks. I.e. the worst thing that would happen is that a frame would be dropped.

The risk vs reward of trying to fix this is heavily skewed towards risk. Assigning to Niklas to figure out if this is something we want to consider in the very long term.
Comment 4 by, Dec 17 2014
Labels: Area-Internals
Comment 5 Deleted
Project Member Comment 6 by, Dec 1
Project Member Comment 7 by, Jan 11
Owner: ----
Status: Untriaged
Moving back to triage since no meaningful updates have happened since more than a year ago. Is this still a relevant issue?
Sign in to add a comment