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.

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

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.

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.

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.

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.

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:

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

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

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.

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.