Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Allegro 5 Threading Interface

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Allegro 5 Threading Interface
Mark Oates
Member #1,146
March 2001
avatar

But it's really necessary do something like that in a real game?

Well, yea. Threads are mean little beasts and they deserve your respect. They're unpredictable and aren't prone to let you know if and when they crash. If you don't go about it the right way, crashes can come out of nowhere and can be impossible to reproduce. You should always approach threaded programming very defensively and take all the appropriate precautions.

Are you making progress on the cURL part of your problem? :)

AMCerasoli
Member #11,955
May 2010
avatar

Yes I already solve it... But it has a little isolated problem, I think it's my code fault.

when I open the window and libCurl download the data and then I close it nothing happens, but if I open the window and immediately close the window then the entire game get stuck again (as you can see at the end of the video). But I think it's because I'm creating a new thread inside an object which is handled by a container which isn't in another thread, so the entire game needs to wait until the thread close. I might fix it, but I don't see it necessary.

video

I would need to kill the thread immediately. ;D

weapon_S
Member #7,859
October 2006
avatar

Fix it you dummy >:( The times you actually know what's wrong, are the moments a programmer should live for!
Might I ask if by chance I've learned the pthreads syntax while learning Allegro?

AMCerasoli
Member #11,955
May 2010
avatar

WTH... I thought this thread was death... It's like the other thread where I put a conclusion and now that I was looking for something that I wrote there I saw two more posts...

To fix this problem I would need to create an entire object of my class in another thread. And if I do it, I have no idea how could I use list to control them, I think I can't.

How can I call an object function from the parent thread using std::list? nahh too complicated. What I'm going to do it's just don't let the user close the window until the data is downloaded or the error message appears. It's less than a second anyway.

Controlling a bunch of threads using a std::list would be good, though.

Imagine a pointer to an object, I created that object on a different thread. But I need to call one of the pointer functions from the parent thread. So, I would need to send some kind of data to the thread where I'm going to store the address of the object that I have created on that thread, and then I would need to create a std::list of pointers on the parent thread, and I think I wouldn't need to use mutex, because if I call the function draw() of some object only that object would be using that part of the memory, right?... Hmmm.. interesting...

But everything would be different, draw() would only set a flag which is going to be used by the thread, since the thread would have its own loop... AHHHHH my brain!!!

I think that is not even possible... anyway, I got inspired for a moment... :P

weapon_S
Member #7,859
October 2006
avatar

I'm creating a new thread inside an object which is handled by a container which isn't in another thread, so the entire game needs to wait until the thread close.

I didn't really pay enough attention to this sentence. I hope you know a STL container can copy it's elements, if it feels to. So I hope you didn't put your objects directly into the container, and the creation of threads into the classes constructor.
You plan on actually using objects in a (container) to dynamically add and remove threads...? Complicated!
Why don't you show what you have now? It should be good for a couple of laughs :P

Imagine a pointer to an object, I created that object on a different thread. But I need to call one of the pointer functions from the parent thread. So, I would need to send some kind of data to the thread where I'm going to store the address of the object that I have created on that thread, and then I would need to create a std::list of pointers on the parent thread, and I think I wouldn't need to use mutex, because if I call the function draw() of some object only that object would be using that part of the memory, right?... Hmmm.. interesting...

The container aside, you want to create a thread that creates an object, that can be used in the main thread? How about just passing a pointer to a struct like this to your child thread?

struct {
   GameData* everything; //optional... beware of concurrency
   ClassName* object_loaded_in_thread;
   int state; //Starting, object ready and running, failed or sumthin.
   ALLEGRO_MUTEX* yeah_still_necessary;
}

You want to run the other thread to? Loading objects concurrently might make sense, but I can't see what you'd have to run in other thread besides that. What should the two threads tell eachother? (Remember I'm a beginner to.)

AMCerasoli
Member #11,955
May 2010
avatar

weapon_S said:

I didn't really pay enough attention to this sentence. I hope you know a STL container can copy it's elements, if it feels to. So I hope you didn't put your objects directly into the container, and the creation of threads into the classes constructor.

No I'm not putting the object directly inside the container. I'm creating a container of pointers. And no I'm not creating a new tread inside the constructor, hahaha that would be crazy, I'm creating it inside the destructor... hahahaha... no really, I'm creating it inside the object, another normal function.

Quote:

You plan on actually using objects in a (container) to dynamically add and remove threads...? Complicated!

Not in my game, I was just wondering how would it be. What I would like to know is how to create an object in another thread and then call its member functions in the parent thread. If the child thread, create a new object, the parent thread have no idea about that, so I would need to send to the child thread the object that I want to create plus a pointer of the same datatype to then add it to a container in the parent thread... Or something like that. :P

Quote:

The container aside, you want to create a thread that creates an object, that can be used in the main thread? How about just passing a pointer to a struct like this to your child thread?

Yes, I think would be something like that.

Quote:

You want to run the other thread to? Loading objects concurrently might make sense, but I can't see what you'd have to run in other thread besides that. What should the two threads tell eachother? (Remember I'm a beginner to.)

Well, in my current game I'm loading from the server for that reason I need another thread, but yhea I don't see another very useful having multi-thread system inside a normal game.

Wait man... I just release that in fact I'm creating another thread inside the constructor... And what is the problem? because everything is working fine here... :-/

Check out if it work on your computer, download it, come on, just 1,5 Mb. Tell me if it work.

Press A to make appear a window and D to delete it. You should see "Cargando.." which is "Loading.." and then a bunch of name and time records. Or a error message if something went wrong.

Edit: I mean, I'm making the thread start in the constructor but the function itself is outside the constructor.

weapon_S
Member #7,859
October 2006
avatar

Anything you do in the constructor should be considered, if using objects directly in an STL container. The program seems to work fine for me (@ 0.5FPS).

axilmar
Member #1,204
April 2001

Does someone have really an example to show a very basic program using the Allegro 5 threading interface?

If you want to use threads in an easy manner, you need to code a worker class thread, into which you send events to it, which are executed in the context of the thread, and that you receive events from.

Assuming that you use c++ (from your reference to the std::string class), you first need to wrap the Allegro mutex into a class, like this:

class Mutex {
public:
    Mutex() { mutex = al_create_mutex();}
    ~Mutex() { al_destroy_mutex(mutex); }
    void lock() { al_lock_mutex(mutex); }
    void lock() { al_unlock_mutex(mutex); }
private:
    ALLEGRO_MUTEX *mutex;
};

Then you will also need a semaphore. Allegro does not contain one, so use pthreads:

class Semaphore {
public:
    Semaphore() { sem_init(&m_sem, 0, 0); }
    ~Semaphore() { sem_destroy(&m_sem); }
    void increment() { sem_post(&m_sem); }
    void decrement() { sem_wait(&m_sem); }
private:
   sem_t m_sem;
};

With the above, you can make a nice event queue, like this:

#SelectExpand
1class Event { 2 virtual ~Event() {} 3 virtual void exec() = 0; 4}; 5typedef std::shared_ptr<Event> EventPtr; 6 7class EventQueue { 8public: 9 void put(const EventPtr &ev) { 10 m_mutex.lock(); 11 m_events.push_back(ev); 12 m_mutex.unlock(); 13 m_sem.increment(); 14 } 15 16 EventPtr get() { 17 m_sem.wait(); 18 m_mutex.lock(); 19 EventPtr event = m_events.front 20 m_events.pop_front(); 21 m_mutex.unlock(); 22 return event; 23 } 24 25private: 26 Semaphore m_sem; 27 Mutex m_mutex; 28 std::list<EventPtr> m_events; 29};

Now, with an event queue at hand, you can make your worker thread like this:

#SelectExpand
1class WorkerThread { 2public: 3 WorkerThread() { 4 m_loop = true; 5 thread = al_create_thread(&threadProc, this); 6 } 7 8 ~WorkerThread() { 9 m_loop = false; 10 al_join_thread(thread); 11 } 12 13 void put(const EventPtr &ev) { 14 m_eventQueue.put(ev); 15 } 16 17private: 18 ALLEGRO_THREAD *thread; 19 bool m_loop; 20 EventQueue m_eventQueue; 21 22 void run() { 23 while(m_loop) { 24 EventPtr ev = m_eventQueue.get(); 25 ev->exec(); 26 } 27 } 28 29 static void threadProc(void *arg) { 30 (WorkerThread *)->run(); 31 return 0; 32 } 33};

The above worker thread implementation is very simple: it waits on the event queue. If an event is received, it executes it, until the flag 'loop' is sent to false.

With the above, you can do subclasses of the class 'Event' to be executed in the context of the worker thread.

Or, if you use a modern version of c++, you can use c++ function objects as events, like this:

class FunctionEvent : public Event {
public:
    FunctionEvent(const std::function<void()> &f) : m_function(f) {}
    virtual void exec() { m_function(); }

private:
    std::function<void()> m_function;
};

EventPtr event(const std::function<void()> &f) {
    return EventPtr(new FunctionEvent(f));
}

Now, you can send any code to the worker thread. Assuming you have the function:

void myFunction(const std::string &str) {
    cout << str;
}

You can tell the thread to execute the function with a parameter like this:

myWorkerThread.put(event(std::bind(&myFunction, "the quick brown fox")));

Finally, if you want to get a result from the thread, for example, be notified when a I/O operation has finished, you can send an Allegro event from the function, assuming you also pass the Allegro event queue to the function.

For example, you can do this:

void receive(CURL *curl, ALLEGRO_EVENT_QUEUE *queue) {
    curl_easy_perform(curl);
    ALLEGRO_USER_EVENT *myEvent = new ALLEGRO_USER_EVENT;
    myEvent->type = MYEVENT;
    al_emit_user_event(queue, myEvent, myEventDestructor);
}

myWorkerThread.put(event(std::bind(&receive, curl, queue)));

And, in the main event loop:

switch (event.type) {
    ...
    case MYEVENT:
        //bla bla do something with the event
        break;
}

Caveats:

  • don't use the same data from the main thread and any worker threads. I.e. if you send a string to a worker thread, don't use it from the main thread (or any other thread).

Advantages:

  • you don't have to worry about synchronization ever again.

Elias
Member #358
May 2000

Why aren't you using any condition variables? Those are easier to understand than semaphores and you can build semaphores with them. And it makes you not depend on pthreads.

--
"Either help out or stop whining" - Evert

Arthur Kalliokoski
Second in Command
February 2005
avatar

Elias said:

Why aren't you using any condition variables? Those are easier to understand than semaphores and you can build semaphores with them. And it makes you not depend on pthreads.

I haven't read the whole thread, but IIRC the reason for pthreads is to prevent different cores from reading various values for the same variable from their respective caches. I believe pthreads on x86-like processors uses the asm xchg mem,reg instruction for semaphores etc. because xchg forces the variable to be written directly to uncached memory.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Elias
Member #358
May 2000

Yes, all threading APIs will do that (Allegro just uses pthreads anyway). Skipping Allegro/pthreads completely and using atomic operations directly for some things would allow implementing certain things with higher performance than using mutexes. But premature optimization...

As I understand it we have ALLEGRO_COND in Allegro for the sole reason that you do not have to use semaphores for anything though, so just saying an example on how you use Allegro's threading API should not have those sem_ functions in it.

--
"Either help out or stop whining" - Evert

axilmar
Member #1,204
April 2001

Elias said:

Why aren't you using any condition variables? Those are easier to understand than semaphores and you can build semaphores with them. And it makes you not depend on pthreads.

Condition variables are not suitable for event queues: suppose two events are put in the queue while the worker thread is busy; the condition variable is set twice, but the worker thread is woken up once; what we need is the worker thread to be waken up twice.

Thomas Fjellstrom
Member #476
June 2000
avatar

axilmar said:

Condition variables are not suitable for event queues: suppose two events are put in the queue while the worker thread is busy; the condition variable is set twice, but the worker thread is woken up once; what we need is the worker thread to be waken up twice.

Or just have the worker get both events out of the queue.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

Something like this (just written by looking at Matthew's earlier example):

#SelectExpand
1class Worker { 2 Queue events; 3 ALLEGRO_MUTEX mutex; 4 ALLEGRO_COND cond; 5 6 void run() { 7 while (!al_get_thread_should_stop(thread)) { 8 al_lock_mutex(mutex); 9 while (events.is_empty()) { 10 al_wait_cond(cond, mutex); 11 } 12 Event event = events.pop(); 13 al_unlock_mutex(mutex); 14 event.work(); 15 } 16 } 17 18 void put(Event event) { 19 al_lock_mutex(mutex); 20 events.add(event); 21 al_broadcast_cond(cond); 22 al_unlock_mutex(mutex); 23 } 24}

--
"Either help out or stop whining" - Evert

AMCerasoli
Member #11,955
May 2010
avatar

Wow, thanks axilmar and Elias, I'll be reading that the next few days.

<quotes>Anything you do in the constructor should be considered, if using objects directly in an STL container. The program seems to work fine for me (@ 0.5FPS).</quotes>

Indeed, I was doing too many thing inside the constructor, now that I'm checking the game in older computers and not so older computers I can see a very bad performance. I should be doing that all the time, and not rely only on mine.

What does mean the (@ 0.5FPS)? I don't have a FPS counter.

axilmar
Member #1,204
April 2001

Elias said:

Something like this (just written by looking at Matthew's earlier example):

Doesn't it have the problem of blocking, even if there is an event in the queue? for example, could the following take place?

  1. worker thread enters 'al_wait_cond'

  2. worker thread unlocks the mutex 'mutex'.

  3. another thread invokes function 'put'. According to the pthreads documentation, "if no threads are waiting on cond, nothing happens". At this point the worker thread is not waiting on the condition, so nothing happens.

  4. worker thread blocks on the condition 'cond'.

While the docs say that the operation condition wait operation is atomic, it also says "pthread_cond_wait atomically unlocks the mutex (as per pthread_unlock_mutex)", so if it uses that function to unlock the mutex, another thread may signal the condition before the worker thread gets a chance to block on the condition.

Is the above possible?

EDIT:

According to this:

Quote:

These functions atomically release mutex and cause the calling thread to block on the condition variable cond; atomically here means "atomically with respect to access by another thread to the mutex and then the condition variable". That is, if another thread is able to acquire the mutex after the about-to-block thread has released it, then a subsequent call to pthread_cond_signal() or pthread_cond_broadcast() in that thread behaves as if it were issued after the about-to-block thread has blocked.

So, it seems like the solution posted above will work.

Elias
Member #358
May 2000

Yes. Basically, both the al_signal_cond and the al_wait_cond are protected by the mutex (a condition variable always needs an associated mutex). And that mutex behaves in the way the pthreads documentation says.

When someone calls put(), they first need to acquire the mutex. They can either do that because the worker thread is working and outside the locked section, in which case the new event is simply added. The subsequent signal will not be "received" by anyone.

Or alternatively, a put() call can get the mutex when the worker thread blocks in the al_cond_wait() call. In that case, the worker thread wakes up (after the al_unlock_mutex() in put), with the mutex locked. It now will re-check if the queue is empty and if it's not grab the next event.

However, I think the kernel scheduler is free to wake up any thread blocking on the mutex. So if there's 10 threads calling put() at the same time and 10 worker threads waiting on the condition variable, after the first put() signals one of the worker threads, any of the remaining 10 contenders for the lock (other 9 put() threads and the waked up worker) may run, not necessarily the worker thread. Not 100% sure on this, but I edited my post and changed al_signal_cond() to al_broadcast_cond() just in case :) With broadcast(), all worker threads wake up, so now no matter in which order the (now 19) contenders obtain the lock, each worker will be working on one event after all the put() calls have been made.

--
"Either help out or stop whining" - Evert

axilmar
Member #1,204
April 2001

Is the broadcast necessary? there is one wait condition per worker thread. No other thread will wait on that condition.

Elias
Member #358
May 2000

Depends on how the threads are scheduled. E.g. if at some point this happens with the * where each thread is, i.e. two threads call put and two workers are blocking:

thread1: * lock / put / signal / unlock
thread2: * lock / put / signal / unlock
worker1: lock / * wait / get / unlock
worker2: lock / * wait / get / unlock

Then what might happen, if things are implemented that way, is that thread1 is first called, signals worker1, unlocks the mutex and now thread2 obtains the mutex (not worker1), signals (randomly) worker1 again and unlocks. Now worker1 wakes up because it was signalled and takes one event. With broadcast this can't happen because worker2 always would have been signalled as well.

Most likely when worker 1 is signalled its state is changed from waiting to signalled and so thread2 would then wake worker2 with its signal (and not signal worker1 again). So broadcast would not be necessary. It can't hurt either though.

--
"Either help out or stop whining" - Evert

axilmar
Member #1,204
April 2001

Elias said:

thread2 obtains the mutex (not worker1), signals (randomly) worker1 again and unlocks

I don't think that can happen. If thread2 signals cond2, then worker2 will be signaled, not worker1.

Unless you meant something else.

Quote:

It can't hurt either though.

What about performance? internally, at the lowest level, when multiple threads are about to be awakened, there is a loop somewhere over the thread structures blocked on the wait condition. Whereas, when there is only one thread to awake, there is no such loop.

Granted, the difference is minor, but I think the fast path is on awakening 1 thread, not many.

It might make a difference somewhere, perhaps on lower-spec'd machines like phones.

AMCerasoli
Member #11,955
May 2010
avatar

I have a (maybe stupid) question.

But, if I'm completely sure that one thread is not going to be using the data that another thread is changing and stuff, I don't need to use mutex, right?

I don't want to stop the hole process but I'm not going be touching the data that the other tread is manipulating until is done. So since the parent thread is going to be waiting for a flag to become true, using an if statement the only variable that I'm going to lock using mutex is that one (the flag), right?.

Here is a scratch code, to get the idea.

#SelectExpand
1 2class DATOS_SALONF_W{ 3 4 public: 5 6 ALLEGRO_MUTEX *mutex; 7 ALLEGRO_COND *cond; 8 ALLEGRO_USTR *names[15]; 9 ALLEGRO_USTR *tieme[15]; 10 ALLEGRO_FONT *font; 11 std::string string; 12 bool ready; 13 14 DATOS_SALONF_W() : mutex(al_create_mutex()), 15 cond (al_create_cond()), 16 ready(false) {} 17 18}; 19 20int main(){ 21 22DATOS_SALONF_W data; 23 24al_start_thread(func_t,&data) 25 26lock_mutex(data.mutex) 27 28if(data.ready){ 29 30 31 // Here I will be using the data that the another thread processed, 32 // But I'm not going to use mutex anymore, because I know the thread 33 // Isn't running anymore. 34 35} 36unlock_mutex(data.mutex) // I don't know where should I put this in case I want 37 // To do something like this... Because while the child 38 // thread is "alive" this is useful, but once the child 39 // thread is "dead" I'm going to be locking a flag 40 // that is going to be true until the program close... 41 // so I think there is something wrong with my implementation.

I think, al_wait_cond in this case isn't useful, because I don't want to stop the hole thread. I want to show something while another thread is processing the rest, but I'm 100% sure that there is another way... I need the concept. And the worker thread and semaphores is too complicated for such simple task, I think...

Edit: I want to do this, to avoid using too many al_lock_mutex otherwise I could have more than one flag, and show resources when they're loaded, something like:

#SelectExpand
1 2al_lock_mutex() 3if(data.flag_bitmap){ 4 5al_draw_bitmap() 6 7} 8al_unlock_mutex() 9 10 11al_lock_mutex() 12if(data.flag_fonts_ustr){ 13 14al_draw_text() 15al_draw_ustr() 16 17} 18al_unlock_mutex() 19 20etc...

axilmar
Member #1,204
April 2001

Quite strangely formed question, I might say. I'd like to help you, but you are not very clear.

Here is what I understood so far: you want one thread to process some data and another thread to wait on the data and use them, right? So, for this to happen using flags, you don't need actually any mutexes or wait conditions, provided that the data are not processed by two or more threads at the same time.

AMCerasoli
Member #11,955
May 2010
avatar

You got it right! :)

Thanks that is what I wanted know.

But the other thing that want to do, is not use mutex anymore once the data is loaded because I don't need it anymore. but I guess is impossible, I would need to make a Pre-load-code and a Post-load-code, and I think that is worst.

Right now I have not too muck time to explain myself but I'll come back with a conclusion. ;D

Edit: al_lock_mutex is too slow? because I realize that is my problem. I don't want to use al_lock_mutex not even to check the flag variable once I have loaded all the resources ::) ... But I guess there is no problem doing so.

And, if I load all the data in another thread because is too slow to load it in the object constructor, then I need to destroy the resources in another thread, or destroying is faster? oh oh... :-/

 1   2 


Go to: