Hi guys,

One of the libCurl function is synchronous (which means you can't continue until the function has completed one way or another). So I would need to do some multi-thread to avoid pausing the entire game while requesting the data from the server.

I have being checking the example (too elaborated to be actually an example) to understand the Allegro thread interface. But what I would like to do is just open a new thread, modified some variables (std::string) and then close it. My question is:

If I create a variable called std::string string, outside of the tread, then send the address of that variable and use a pointer to modified that variable in the thread, but at the same time I might be using it (not modifying it) the variable outside the thread, do I need to use mutex and things like that?

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

Thanks.

Check out the multi interface.

Yes.

Why don't you create a little example using libcurl and an Allegro thread and then post it here for comments?

It says:

1. Enable a "pull" interface. The application that uses libcurl decides where and when to ask libcurl to get/send data.

2. Enable multiple simultaneous transfers in the same thread without making it complicated for the application.

3. Enable the application to wait for action on its own file descriptors and curl's file descriptors simultaneous easily.

There is no multi-thread. Besides I don't need multi handle since I'm doing just one call to the server to just one specific file. I don't need to retrieve nor check multiple calls to server.

Here, and probably the wiki, and probably should be inside the examples binaries too. there is thread.c and thread2.c and as the name says (thread2.c) it's even more elaborated, with more functions, structs, and unfortunately the mutex thing.

Sorry but there is nothing you could do right now, I'm going to still struggling with thread2.c file to get to the point. I just wanted to know if I had to use mutex because without using it I already know how to do it, but using the mutex thing I have no Idea, I'm going to have to read more.

Assuming you have some variable named foo that is shared, you can do something like this:

// call this once at the beginning
ALLEGRO_MUTEX *m = al_create_mutex();

// within the various threads, do this any time you want to access the variable
al_lock_mutex(m);
// use variable foo
al_unlock_mutex(m);

// call this once at the very end
al_destroy_mutex(m);

Ok, thanks Matt, that helps me solve my particular problem, don't know if I'm doing it correct, though.

But I'm trying to create a little example to put it on the Wiki, but I don't know if I'm using the functions correctly.

I took a Wiki tut and modified a little bit.
Anyway here it's:

Concept: Change the X axis in one thread and the Y axis in another thread of a bitmap.

Well, there are some comments on the source about things that I can't understand, all the thread thing it's very new for me but I think it's incredible powerful.

I was also trying to add the feature, to allow the user to start or stop the movement of the bitmap, but I think I need conditionals, because suppose that I have a bool called run inside DATA I can't do something like this:

while(data->run){

      if(!modi_X)
         data->posiX += num;
      else
         data->posiY += num;

}

It doesn't do anything, it's like the thread thinks run still being false, even when I'm changing it outside the thread (data.run = true).

So for easy answers:

1) So in the first code comment when I said "//Why without this doesn't work?" why is that happening? why without al_rest() the data info is sent incorrectly? it's because takes more time to change data.modi_X = true than create a new thread, so the new thread receive the old data?

2) In the second comment "//If I don't use this, I'm not seeing the image because I'm adding 'num' too fast?" I guess that is because even before allegro create the windows this thread is created and the num variable increase its value too fast? and why if instead of add 0.1 I add 0.000001 and delete the al_rest() line just works for some steps and then do nothing?

3) Can I call al_destroy_thread() inside the same thread? I'm using that in my code (not this one, here I'm not destroying the threads yet) but I don't know if is doing something... I have no error.

4) To check if a struct or class variable has change do I need to use conditionals?

Damn, this looks like a FAQ...
Well this is all... For now.

Just a couple of things quickly:

• The mutex must be pointing to the same object in order for it to work. So the mutex should be a member of the DATA class.

  
  

• The thread function checks al_get_thread_should_stop() inside its loop. If that is true, then it gracefully returns out as soon as it can. The outer function that created the thread is responsible for destroying it.

volatile?

The 'volatile' keyword simply means the compiler shouldn't optimize code that uses that variable, for instance the timer tick, the compiler could just load a copy into eax and wait forever to see if it changes all by itself (and the timer thread could hardly be expected to do that).

Ok ,I have modified the code:

Now I'm destroying the thread at the end of the program, and initializing mutex inside the class data. But most of my questions still there, though.

Here are some Images about what happens on different processors:

AMD Turion 64X2 (2 processors)
{"name":"604160","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/5\/a57ec36cccc29065e694a03571e4b156.png","w":636,"h":481,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/5\/a57ec36cccc29065e694a03571e4b156"}

Intel P4 (1 processor)
{"name":"604162g","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/6\/169e967e5502215a8f2ab750b7f9ea57.png","w":633,"h":478,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/6\/169e967e5502215a8f2ab750b7f9ea57"}

Intel Atom N450 (1 processor, and 2 threads? that is what says the webpage)
{"name":"604161","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/4\/c4e854283698a1c85714a39f52af37c7.png","w":632,"h":472,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/4\/c4e854283698a1c85714a39f52af37c7"}

I'm still thinking why I'm getting those results.

You can't create your data object before main() because Allegro functions (like al_create_mutex) must not be called before al_init.

First of all I'm using this as an excuse to look into threading ( I don't know shit )

My guess: both threads will be set to modiX = true;

That comment seems very correct.

By the way, there is a nice optical illusion in the last one. (In fact it is not impossible).
I assume what you see here is the kind of unpredictability of threads you here about. (I.e. the windows(?) task scheduler.)
And maybe you want to unlock the mutex before resting in the threads.

Damn! you hit the nail weapon_S!! I was overlooking that, now in all computers shows the same, like the P4 picture, Except if I open another program in which I can see a very little variation in the image.

Yes I know that, the question is, why?

And my only answer is: because takes more time to change data.modi_X to true than create a new thread, so the new thread receive the old data?

Here is the last update.

When you don't insert that rest, the modi_X gets changed before the other thread reaches line 152. Whenever you are reading/writing shared data you should mutex^[1]. So that would also go for reading/writing modi_X.

I still don't get it

If what you say is true: "When you don't insert that rest, the modi_X gets changed before the other thread reaches line 152." shouldn't work correctly?

I think what it's happening is that if I don't insert that rest, the modi_X gets changed after the other thread reaches line 152. Isn't that right?

It would need to be something like this:

Parent Thread

• Create data object

• Set modi_X = true

• Create / start thread #1

• Wait for signal from child thread #1

• Set modi_X = false

• Create / start thread #2

• Wait for signal from child thread #2 (technically optional)

Child Thread #1

• Initialize self, read modi_X

• Signal parent

Child Thread #2

• Initialize self, read modi_X

• Signal parent

Here's a sample program:

Note how it uses a signal (condition) along with a "ready" flag that tells the parent that the child has read the x value.

oh yhea, now it's working without al_rest().

thread-0.0.3

Isn't just beautiful? simpler couldn't be (Matt don't do it)...

You cannot omit the ready flag because the child might broadcast the signal before the parent is ready to catch it.

To test that theory, place a short rest before the parent waits for the signal. If you give the child enough time to initialize, then the parent will get stuck waiting forever.

When programming with threads you can never assume the order or speed in which two things in parallel happen.

Ok I think now I get it.

What do you think?

I would like to delete the <stdio.h> include and add the native dialogs addon but I think that would complicate a bit more things for a newbie.

al_wait_cond is weird, but I get it. Except for:

Somebody wants to explain that to me, please?

it was told to by the system.

Ha, I get it now
I'm getting the image of an office where an employee is told by his boss to "do something"; even though the said employee has to wait for some copies to be done. He shrugs and resumes waiting.
When he gets the signal his copies are done, some other guy might have swiped them already, though.

When drawing the bitmap, you could do something like:

float x, y;
al_lock_mutex(data.mutex);
x = data.posiX;
y = data.posiY;
al_unlock_mutex(data.mutex);
al_draw_bitmap(bouncer, x, y, 0);

It won't hold the mutex lock as long, and generally that's a good thing.

I guess it's a good way to show the importance of blocking and unblocking the mutex the less possible. But it's really necessary do something like that in a real game?. Because that would imply creating a whole system to avoid having dispersed variables all over the code.

The entire example is contrived, so it really doesn't matter.

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?

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.

I would need to kill the thread immediately.

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?

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...

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

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.)

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.

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.

Yes, I think would be something like that.

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.

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).

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:

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

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.

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.

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.

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.

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

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.

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:

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

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.

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

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.

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

Unless you meant something else.

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.

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.

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:

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.

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.

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...