[gst-devel] Cothread locking design

[Erik W. <om...@te...>]

In our discussions yesterday, matth and I decided that if we can find a
way to ensure that code from the same element doesn't run simultaneously,
we don't have to worry about things being run from different thread
contexts.  Thie led to the following idea:

We can lock individual cothreads using atomic variables.  Each cothread
has an atomic variable, which is held for the duration of that cothread's
run on the processor.  Before cothread_switch() actually does the
setjmp/longjmp, it releases the lock on the current cothread, and acquires
the lock on the new cothread.  First implementation of this will spin to
attain the lock, future implementations could use a condition variable.

Then we can put locks around get_arg, set_arg, and anything else we need
to lock.  get/set can be implemented by adding a GstElement implementation
of each that acquires the lock and calls a GstElement class method by the
same prototype.

This same method can be used to handle remoted objects, just make sure we
use a GstElement-level get/set, and we can replace the Element class'
get/set as necessary.

This is going to be implemented over the next hour or so in the INCSCHED1
branch.

      Erik Walthinsen <om...@te...> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_