GNOME Bugzilla – Bug 311496
Race condition in optimal scheduler
Last modified: 2005-08-29 15:29:04 UTC
When the gstreamer application is multithreaded and the threads begins with queue, the queue between the threads is used by both threads. In gstoptimalscheduler in function schedule_group near line 1233, the reference count of group->entry, which is a queue in my application, is increased and later decreased. But because the queue is used from two threads, race condition occurs while increasing/decreasing reference counts. The result is that the reference count gets decreased to 0 and the queue is destroyed, which breaks the pipe and the application halts. On SMP machine, this bug appears in 5 minutes. The patch, which will be uploaded in a minute, fixes this by surrounding the refcount increase/decrease by mutex lock and unlock. This might not be the correct solution but it helps (the application with the patched gstreamer did not halt yet).
Created attachment 49723 [details] [review] Possible patch
Created attachment 49845 [details] [review] Better patch This patch is much better (but there still might be a better fix). Some refs/unrefs happen in other places of scheduler too so when all refs/unrefs are protected by a mutex less race conditions happen.
I considering dupping this to #166020, which is about refcounting thread-unsafety in glib (and which was fixed for the yet-to-be-released glib-2.8). We indeed are aware of the issue, but we'd rather not take locks to workaround bugs that are not our own...
Definitely a dup to #166020. Should work better with GLib >= 2.7.3. Note that GStreamer 0.8's threadsafety is poor; consider moving to 0.9. *** This bug has been marked as a duplicate of 166020 ***