Submitted by Michael Rubinstein

Link to original bug (#697441)

Description

Rare clock jumps of around 4.3 seconds were seen in a 32-bit Windows application. GStreamer and the app were built with MinGW/GCC, so the problem probably applies to any 32-bit environment.

The reader/writer locks in gstclock.c guarantee consistent calibration values. However, they don't make load/stores of "last_time" atomic.

Here's where I think the problem occurs:

The value of time is close to a value that would carry from the low word to the high. Say 0x00000000 FFFFFFFF.

A thread is executing:
priv->last_time = MAX (ret, priv->last_time);
It has read the FFFFFFFF

Another thread interrupts the first and updates last_time to
0x00000001 00000000

The first thread resumes and reads the high word yielding
0x00000001 FFFFFFFF
which it stores in last_time.
Note FFFFFFFF is around 4.3 seconds in ns.

My fix is to use GST_OBJECT_LOCK/UNLOCK in place of read_seqbegin/read_seqretry. This has no measurable performance impact in my application. It seems to fix the problem, but since the problem occurs rarely, more testing is needed.

Version: 1.0.5