If you want something more complicated, elaborated, etc... check out Peter Wang´s ex_thread files... The tutorials in the wiki give you the concept so you can get it faster, then you can complicate you code all you want.

Peter's examples shows you that you can create events inside a thread. you can do whatever you want inside a thread. But you must be very carefully with data exchanging.

Insted of a int main(){} you have a static void *thread_func(ALLEGRO_THREAD *thr, void *arg){}

You could do it, but I think that instead of making clearer your code, could make it more complicated if you're not careful, since you're going to need to exchange a lot of data, depending on your game of course. To me, a thread for just the AI is too much, but I may be wrong.

Yeah, they are afaik. Thats why they were designed to be so annoying. Events are coppied into each queue, etc. But when I last looked at it, it was thread safe.

I assume yes.

Each event source at the very least has a mutex/lock. I'd think the event queue may as well. I'd have to check.

You also only have to save/load inputs to make a replay function (assuming the rest of your game is deterministic).

You need the Active Object pattern.

I have attached a sample implementation that solves the Dining Philosophers problem very elegantly.

Basically, concurrency comes down to state isolation: you can have as much of a concurrent state as you wish, as long as it is isolated from the rest of the world.

So, the Active Object pattern doesn't do anything groundbreaking: it just offers a way to isolate state: each active object instance is the only instance that can manipulate its state; all other active objects (i.e. all other threads) must issue a request to that object in order to modify state.

But the good thing with this is that state can be shared if state is an active object! you can have active objects passed around to other active objects, as if you were passing normal objects around, but you would not have concurrency issues.

If you check out the code I posted, feel free to ask questions.

So you have 3 objects from the above description:

• the map.

• the human player.

• the AI player.

If you make the objects active, then you can pass the map object to both the human player and the AI player. And then you can make the AI player 'think' for as long as it likes, being a separate thread, while the AI player modifies the map in parallel.

Not sure if I'm too late to the party on this thread but I thought I'd add my thoughts on this

Putting AI into a separate thread is a perfectly reasonable thing to do. In fact, it almost makes sense because it means the computer is now "thinking" separately to player input and the responses may be more natural.

The last project I worked on was a flight simulator for one of the big defence corporations. Our design had every flight system running as a separate process. There were never any issues in terms of timing or coordination of the AI between CSCIs (NB: this wasn't a personal project, it was my normal job).

It was a multi-process simulation, not multi-threaded, but the paradigm of separating the logic processing performed by CSCIs was the same. I did the flight model and weapon systems for the simulation and having them in separate processes meant the weapon systems couldn't "cheat" by directly accessing exact environmental data. They had to go by the data the instrumentation CSCIs fed them.

The AI for the enemy craft went into the tactical CSCI, which was run on a separate machine altogether. This kept the CSCIs for the enemy AI totally separate from the CSCIs that the pilot/player controlled.

This flight simulator cost $30 million to make. If putting AI processing in separate CSCIs is good enough for that it's certainly good enough for small personal projects.

I think those problems are alleviated by using the right abstraction. For example, active objects.

The Dining Philosophers problem is used as an instructional tool for the complexities of using threads, demonstrating how easily potential dead-locks, live-locks and data races can be introduced by using mutexes, semaphores and wait conditions; however, by using the Active Object pattern, I managed to write an example implementation of it effortlessly, without using any synchronization mechanism, and the result (seems to) not have any of the aforementioned problems.

I am a great believer in this pattern. I've used it quite successfully in many projects that required multitasking. I have yet to find another pattern that allows multithreaded programming to be as easy as non-threaded programming.

And the good thing with the active object pattern is that you can add as many features as you want, but concurrency will not be affected.