Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Threading question

13 views
Skip to first unread message

bitrex

unread,
Nov 23, 2016, 1:02:51 PM11/23/16
to
I'm working on a little graphics engine using the Allegro 5 library:

http://liballeg.org/

I'm writing it in C++, but the library calls are all C.

I have my demo working OK at the moment, but what I'd really like to
have is two threads: one taking care of handling the display rendering,
and one to run the script on the underlying objects and update their
positions, effects, etc.

Towards this goal right now the "visualizer" class which contains the
main display loop has a member std::map which holds shared_ptrs of an
"AbstractDisplayObject" type/interface, which defines a few pure virtual
functions for all the stuff you can do with a display object: update its
position, change its projection transform, render it to the screen, etc.

It's then subclassed by say "DisplayObject2D" for a 2D sprite where the
methods are overloaded appropriately and a unique_ptr to the texture
resource is created on instantiation. Adding another object to the
display is then just stuffing a new shared_ptr instance from the class
which composites say a "DisplayObject2D" into the map, and then
iterating over it each frame.

When a display object is removed to the script it passes a message into
the event queue telling the visualizer to dump its shared_ptr from the
map by ID-lookup before the object holding the first shared_ptr to the
object goes bye-bye.

So Allegro also has a C threading library which seems to be a layer on
top of POSIX threads:

https://www.allegro.cc/manual/5/allegro_thread

It has mutexs and conditions. Clearly I don't want the visualizer
pulling vector coordinates from a display object reference while the
other thread is writing to them.

First question: since I'm using C++11, is there a good reason to use the
C threading implementation provided by the library over std::thread?

Second question: if it's the former, what's the best way to wrap up that
API in a class where I can pass in another class instance, say
containing an infinite loop public method for the thread job, such that
the resource locking on the display objects is handled automatically?
The C threading API requires all thread functions passed as callbacks to
the lib to adhere to the following prototype:

static void *Func_Thread(ALLEGRO_THREAD *thr, void *arg)

Where the latter argument is used to pass in a reference to some fashion
of structure containing the conditions, mutexes, resources to be locked,
etc.
0 new messages