New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: Untriaged
Owner: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Windows bug in webrtc/system_wrappers/interface/tick_util.h

Reported by, Apr 3 2013 Back to list

Issue description

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 2016

Project Member

Comment 7 by, Jan 11 2017

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?
Project Member

Comment 8 by, Sep 27

Ping for triaging.

Sign in to add a comment