First off, I want to give a shout out to iarwain for the lovely thread implementation. Seeing semaphore abstraction got me all excited.
My question is about planned features for the Thread module. Since semaphores have been added, are you also going to be adding other synchronization structures such as monitors and channels? If monitors are going to be added, which types (Hoare, Mesa, both)?
If a user wants to do synchronization, monitors might be safer (and easier) for them to use since both Java and C++11 have them.
Channels might be more useful to orx since it makes for nice thread communication. I know some other engines have implemented Threads and Channels exclusively rather than full synchronization support.
I have to admit it's rather unusual that someone's first question here is that low level and even more when it's about code that is only on a dev branch so far.
As you've probably noticed, I tend to limit the low level constructs to orx's own needs. That's why you won't find a lot of traditional data structures there, like the myriad of standard containers such as queue, deque, vector, ...
Likewise, I briefly thought about adding monitors/condition variables at some point but didn't go further as it's unlikely I'll need those for orx itself.
I hadn't given any thoughts to channels yet, but I might consider it in the future as it sounds like a pretty good idea, thanks for suggesting it.
In the current state, I'm more likely to add support for atomics and some lockless containers (probably queue). However I only added full-fledged memory fences so far and I'll have to refine that as well.
So, as you can see, nothing has been decided yet. Orx is still widely mono-threaded and it's going to evolve slowly but steadily.
I got the biggest contention points (ie. I/O accesses) offloaded to separate threads and am currently finishing the adaption of the profiler so that markers can be displayed on all running threads in a consistent fashion.
When that is done, I'll have to adapt the iOS sound and display plugins and wait for Lydesik to do the same for Android. Then it'll be time to merge everything back to main and wait for some more testing before making a new release.
When all this is done, I'll be happy to make the threading support evolve and make sure key modules such as the config one become thread safe.
I have quite a long list of personal TODOs, in addition to all the open requests, and will work on them regularly.
To sum it up, I don't have plans for all those higher level synchronization constructs at the moment, but I'm open to discussion and will likely end up integrating some in the future. Any suggestions, like the channels you mentioned, are more than welcomed.
I was just interested when I saw it mentioned so I looked at the code and was pleasantly surprised. Overall this engine looks fabulous.
Both my main computers died a couple months ago, so I haven't been able to do much high-level programming. Waiting on a new build so I can start playing with orx!
In the mean time I've been reading the wiki a lot. The only missing page that stood out is the savegame page. The tutorials have been very helpful, and reading past questions on the forums has answered some of my more specific questions.
Ah, that makes sense. It's true, anyone who wants higher level structures could just write them using the low-level structures you've added already.
Fancy! What do you mean by markers?
Cool! And yeah, I'm sure there are bigger fish to fry right now. I was just curious.
Hope you'll have the same opinion after digging further into it.
Ah yes, I should probably do something about the savegame. As well as the commands/timelines and the resources and all the new systems that have appeared since I last wrote something on the wiki.
Till then, you can read more on those on the orx-dev group.
Indeed. Plus most users use their favorite libraries, were they STL or custom. That being said I really like the idea of channels.
Ah yes, I'm too much into it that I forgot to give proper context!
I was referring to the profiler markers. As the same markers could have been used across more than one thread, that gave me some issues I had to fix. Same for the profiler information collection pass. Right now everything is almost working fine beside the threads that are stopped via semaphores and don't reset their data properly every frame (as they aren't currently running, obviously). Hopefully I'll fix that soon.
Curiosity is good. More opinions and suggestions make for a better engine. I'm all for that!