Re: thoughts on smp

Hi,

On Sat, 21 Feb 2004, Enrico Weigelt wrote:
> does anyone know how SMP exactly works ?

Yes. Lots of us do.

Threads/processes (in this respect, they're the same; the only difference
is that the one shares a process context and the other has two separate
process contexts, unless you use Shm in which case the two are
interchangeable) are switched over one or more CPUs as the kernel feels
right. Variables can be read by multiple threads at the same time and
variables should be protected while being written to (to prevent reads or
other writes), which is called criticical regions.

This is far too complicated for the "simple" plugin system that you guys
propose, and for applications that GStreamer wants to be a backend for,
which is why you ususally wrap this inside your system. In GStreamer, for
example, we have a thread object which is a simple container running its
own thread. So:

file source -> decoder -> audio output

Is one-thread

file source -> ( decoder -> audio output ]

is one-thread, with the ast two elements being in a container. In this
case, it results in nothing, but you get the idea. The container here is,
therefore, only virtual.

file source -> { decoder -> audio output }

is multi-thread ("{" and "}") and runs on multiple CPUs. Apart from that,
the only thing that has to be thread-aware is your framework, since every
element runs inside its own context and doesn't touch context of other
elements unless via the framework-provided functions.

Elements can be multi-threaded internally, in which case they *have* to be
thread-aware. This is a tough job but there's enough libs/elements doing
this already (libmpeg2enc/libmplex from mjpegtools, xvid, probably more).
Make sure that the data context (input/output) of the element run in one
ingle thread - which *should* be the framework-thread, or you'll get
really bad results. This is quite obvious, however. :).

Anyway, that's what GStreamer does and allows. There might be more ways.

Ronald