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?

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?

Yes.

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

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.

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

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.

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:

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?

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.

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

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

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"}

al_rest(0.01); // If I don't use this, I'm not seeing the image because I'm adding 'num' too fast?

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.

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?

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.

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.

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.