Well, in a room, don't we have objects running in parallel (in the step event) ?
Josh already replied, but I will clarify how it all runs now (at least I think I know). Just like in GM, ENIGMA runs sequentially on one core. All of the instances are run in order sorted first by depth and then by id. And all of the events are executed in a certain order, like the first one is create, then step and then draw, but there are many more events. The execution order is the same as the order in which LGM shows them (at least it should be). That is why Create is always before Step and Begin Step is also before Step in the LGM object editor. So if you have three instances, one instance is object0 with depth=-5 and two instances of object1 with depth 0.
The id of the first object1 instance will be 0, the id of the second object1 instance will be 1 and third will be 2 (in reality they are a lot bigger). There are going to be 3 events - create, step and draw. Then every frame this is the order it will execute:
Create for object0 instance with id 2;
Create for object1 instance with id 0;
Create for object1 instance with id 1;
Step for object0 instance with id 2;
Step for object1 instance with id 0;
Step for object1 instance with id 1;
Draw for object0 instance with id 2;
Draw for object1 instance with id 0;
Draw for object1 instance with id 1;
After this it will do some internal work (swap buffers, get input etc.) and then do it all again the same order. Internal work is also done between events.
Also when i call the instance_create to start the animation, it's like an asynchronous call.
Animation is automatically done between events. Like image_index+=image_speed is done before Draw event. Like in previous example it would show up as:
Create for object0 instance with id 2;
Create for object1 instance with id 0;
Create for object1 instance with id 1;
Step for object0 instance with id 2;
Step for object1 instance with id 0;
Step for object1 instance with id 1;
Advance image_index by image_speed for object0 instance with id 2;
Draw for object0 instance with id 2;
Advance image_index by image_speed for object1 instance with id 0;
Draw for object1 instance with id 0;
Advance image_index by image_speed for object1 instance with id 0;
Draw for object1 instance with id 1;
I don't know this is entirely accurate because I don't remember the event order from the top of my head. But the idea is that it all runs in order. Nothing is done in parallel.
Josh, while we could do parallelism for some things I think we realistically cannot do it for most. We can just give users the means to do it for themselves. Like adding functions to create threads and control them. As we don't have functions per se (just like GM), then threads would just execute scripts. Like thread_create(scr_script0) and then it runs in parallel. If something breaks because of some race condition then it will probably be the users responsibility to add mutex and semaphores. Also OpenMP could be useful as an extension. So a very heavy loop could be made to run in parallel just by #pragma omp parallel for.
I also know that there already were some threading functions in ENIGMA. I don't know if they really worked though and where are they now.