Re: Thread safe event loop
Hi,
jonathan@sliid.org wrote:
My first thought was to create a "message" and add it to an event
queue 'as quick as possible'. Say,
last_queued_message->next = &my_newly_created_message;
I recognize that if I have two threads doing this at the same time
they could theoretically both write to "next" and one of them will be
lost. Can I get around this in C++?
currently not. You need some synchronization library. If you have qt,
you probably also have pthreads.
But you are not portable anyway, because C++ won't let you start a
thread and qt not C++ standard. So the discussion about 'standard' is
academic.
Do I need to use cmpxchg (I'm on x86)?
If you want to write your synchronization construct by your own, feel
free to do so. But keep in mind that you will also need a signal to
notify the player thread about the new message. And you have to protect
the root pointer of the queue.
In any other way look for a thread safe queue class or simply use a mutex.
To give some more hints:
If you want your player to be really responsive in almost all cases you
need at last 3 or 4 threads.
- Thread 1 GUI, no I/O must be done here.
- Thread 2 the decoder, also feeds the sound and/or video device.
- Thread 3 Controller (queue consumer), controls the decoder state, also
when the decoder is currently busy or paused.
- Thread 4 Retrieves data asynchronously to prevent the multimedia
devices from running out of data while Thread 2 is blocking at an I/O
function, although enough data is in a buffer.
Furthermore the GUI might like to be informed about executed or failed
commands. So you need a command callback.
If your platform supports asynchronous I/O you will not need the 4th thread.
If you deal with large playlists, you might also want to start a worker
thread, that loads and stores information without passing the object to
the controller thread. In case the playlists can be nested, more than
one worker is recommended.
Marcel