GitLab

Submitted by Edward Hervey @bilboed

Link to original bug (#792595)

Description

Currently the following scenario can happen.

• Thread 1 (from downstream elements) wants to reconfigure the scheduling mode of an upstream element (such as typefind)
• Thread 2 (from the application or higher-level element) wants to deactivate the scheduling of that element.

The following "race" happens:

• T2 calls gst_pad_set_active(pad, FALSE)
  ** T2 calls activate_mode_internal(pad, ..., FALSE)
  ** T2 pad was currently active, it eventually calls pre_activate(pad, GST_PAD_MODE_NONE), which sets in_activation to TRUE and GST_PAD_MODE(pad) to GST_PAD_MODE_NONE
  ** T2 calls the actual activation function
• T1 calls gst_pad_activate_mode(pad, ..., TRUE)
  ** T2 calls activate_mode_internal(pad, ...., TRUE)
  ** T2 has GST_PAD_MODE_NONE, so carries on to call pre_activate
  ** T2 in pre_activate sees that in_activation is TRUE, so waits for the other thread to finish (and set in_activation to FALSE)
• T2 finished calling the actual activation function and calls post_activate
  ** T2 set in_activation to FALSE and resumes succesfully, i.e. telling the caller that the pad is deactivated
• T1 can resume activation and actually activates the pad

=> T2 assumes the pad is deactivated .... but it's not. (Note that the exact opposite could also happen).

Not entirely sure how this could be solved though.