Multithreading & video

SDL Development
21

Okay. In order to implement fully parallelized access to a video surface:

  1. Add support for a list of mutexes to the surface.
  2. For every drawing operation:
    a. Test to see that the area being updated is NOT locked by checking EVERY mutex in the list of mutexes.
    i. If lock found, sleep, busy-wait or whatever and try again from 2.a.
    ii. if no lock found, try to acquire the mutex on the mutex list.
    1. if cannot get mutex on list of mutexes, sleep, busy-wait or whatever and return to 2.a (yes, you must recheck all mutexes).
    2. Now that list-lock is aquired, add mutex for the region being updated.
    b. Do blit
    c. Try to acquire list-mutex.
    i. If unable to aquire list mutex, sleep, busy-wait or whatever and return to 2.c.
    ii. Now that you have list-mutex, remove the mutex from the list.
    d. Return from drawing function.

You ensure here that no areas of a surface is accessed by two threads at
the same time. If no other thread is currently blitting there, you do
the blit. (I would simplify this by just using one single mutex for the
whole surface. I don’t want to access a single surface at the same time
anyway, I want to access different, not related surfaces at the same
time.)

But this would allow multiple threads to use the blit function at the
same time (for example on completely not related surfaces). Isn’t that
exactly what would not work when the interface, i.e. the blit function,
is not multithreading safe?Am Freitag, den 08.08.2008, 20:22 +0100 schrieb cullen e.a. (eac203):

22

Given that SDL currently has some restrictions on what you can and
can’t thread, the best solution - if your really need to implement
drawing from different threads - is to implement a message queue.

That is, rather than writing to the surface directly, you call a
function that adds the drawing operation onto a list of things to do.
Your main thread periodically executes the drawing operations in the
queue (either automatically or when a function is called).

What, if the main thread is already bound to other things, for example
any other queue I have to handle there which is for some reason also
bound to the main thread? (I cannot think of any right now, but like
OpenGL binds a context to the main thread, perhaps other things do that
too.)Am Mittwoch, den 06.08.2008, 14:58 +0100 schrieb cullen e.a. (eac203):