Multi-threading/asynchronous resources Print
10 August 2014

Hi all,

First, as you've noticed, the website never went down and there was no follow up from my host. So I guess so far, so good. ;)

 

Yesterday, I finally finished the iOS version of asynchronous resources handling (texture/sound) and merged the "thread" branch (which I have been using for over 10 months for my own projects now) into the "default" one.

That means a few things:

- orx now support asynchronous resource accesses.

You'll notice that saving a screenshot or loading textures and sounds won't block the main thread anymore, which used to result in the rendering being paused for a short duration. The immediate side effect is that there might be a slight delay when playing a sound for the first time or a white rectangle being displayed while a texture is getting loaded (though that temporary texture can be redefined at will if you'd rather have, say, a transparent temporary texture). In most cases you won't notice those, especially in release builds. However if that becomes an issue, one can easily pre-load assets with a simple loop and even render a progress bar as the engine execution won't be stopped while loading anymore. Config files are still load/saved asynchronously.

Lastly, if you were handling your own resources manually, you can either have synchronous calls or asynchronous ones by simply passing a callback to the read/write function: no callbacks -> synchronous, callbacks -> asynchronous.

 

- orx supports multithreading and exposes a unified API to create, pause, delete, enable, ... threads as well as semaphores for synchronization primitives. There's also a memory barrier macro available for those of you that would need it. Only a full blown read/write one has been added for now. There's no unified thread local storage support yet due to the annoying lack of standard around the __thread() keyword.

 

- profiler markers are correctly handled over multiple threads. And so is the profiler in-game display. By default, page up and page down allows one to display info about other threads.

 

- orx does have more than one thread running. Resources calls are all done in their own thread, same for sound streaming and lastly a generic purpose worker thread is available for tasks created with orxThread_RunTask(). I should probably add a tutorial on this function at some point as it has some interesting properties regarding sequencing (and helps removing the need for explicit synchronization primitives).

 

- most important of all: orx's API is *NOT* thread safe, for the most part. So if you were to use the aforementioned orxThread_RunTask(), make sure your tasks are not calling any orx functions. So far the only module that has a thread safe API if the orxThread one itself. orxProfiler is also mostly thread-safe. But that's about it. So please don't do any orxConfig_* calls in an asynchronous task. I'll add thread safety later on when I've settled on a good performance/safety compromise.

 

In addition to all this, another important news about the "default" branch is that the MinGW32 version now uses gcc 4.8.1: I've retired the good ol' gcc 4.6.2.

 

I should be releasing orx 1.6 officially shortly, unless any big issue is uncovered. Don't hesitate if you have any questions! :)

 

Cheers,

- iarwain

 

Last Updated on Sunday, 10 August 2014 03:20