ID:979126
 
I've recently gotten a hold of Visual Studio 2012 Express for Desktop to perform such tests with BYOND. While there might be an issue with it as a development platform for XP users, I have read it can target XP as a platform.

With LordAndrew's assistance with testing, I have managed to confirm a working form of C++11-styled threading without a single error. I'll let y'all test it out if y'all want (should work for XP users): https://dl.dropbox.com/u/24250760/BYOND/Test%20Versions/ DLL%20DM%20Test%20MKII.zip

Test 1 verb enables another thread while the View Test verb shows a value from an object created with a different class (being changed by the function object used by the thread). When you exit Dream Seeker or even Dream Daemon, it will detach the thread before destroying the whole world which leads to no crashes!

Let me know if y'all are having issues with the experiment such as platform related issues. Shouldn't need to install runtime packages (since I made where such a thing is not required). With C++11-styled threading and proper usage of it, one could possibly harness the power of it.

What would be interesting is if another IDE or another compiler can be used to achieve this (as long C++11 is supported). While it may not serve much purpose for some, it definitely serves special purposes for different tasks such as needing to access speech recognition (which itself requires another thread to function properly or it will lead to server freezing).
Unless you can run DM code in multiple threads, this isn't that interesting.

Threads have been around for over 15 years - it was just an OS feature instead of a language feature. Windows has the CreateThread function to create a thread. Linux has pthread_create.

(Edit: Just to clarify, I got the impression you thought threads were a new concept. Or are C++11 threads somehow different from other threads?)

Any C or C++ compiler will be able to create programs that use threads using OS-specific APIs.
Bandock is just trying to look smart. C++11 standard's std::thread is simply an interface that wraps Windows's, Linux's and other OS's threading functions, to eliminate difference and increase cross-platforming.

I don't think threads will help much, since BYOND worlds get hosted in single thread environment and calling .dll functions is extremely slow process because of data conversion. If we had access to internal pointers it could be useful, since we'd be able to modify atoms directly.
Writing your game as a "module" is much more impressive. Then separating out your "game world" into "modules" that run on "cores" or single core vps instances is how you would achieve a "threaded" world with byond. The cool thing is, all the power to do this is already in our hands. You just don't see it being used very often.
In response to Immibis
Threads are not a new concept (since I first used threading in a DLL file since DLLs/SOs were first supported for BYOND back in 2008). I just created this forum post/thread to show that C++11-styled threads work under BYOND conditions. I used to use Win32 styled threads with it (as well as experimenting with POSIX threads) for handling different experiments. However, Dream Seeker (if you host it) or Dream Daemon now crashes upon exit (if the threads are not properly closed). I have gotten Qt threads to work along as stated C++11-styled threads without such crashing (since they enable proper closing).

Now, I did not use threads for performance gains. As Zaoshi stated in his post, BYOND operates under a single thread which if you try to do any task that requires a lot of processing or looping in a DLL file, it will freeze/hang the server. That is where thread creation can be very useful in BYOND.

While BYOND only allows for server-side usage of DLLs/SOs natively, I have been working with attempts at client-side usage (which will make threading even more useful since there are tasks that will even need it to prevent freezing). Threading is handy for Speech Recognition (I once did a demo over this, though it was only server-side), Window Creation (though not that useful for server-side, would be handy for client-side), and some other unmentioned tasks.

About internal pointers, that would be very awesome Zaoshi. Might require some tricky work, but I could try to find a way to get that working. That would really make DLL/SO usage even more awesome. :D
Just thought I would alert that proper XP support has now been added to the DLL. Apparently, XP support wasn't truly available yet at the time I released it. However, the link on my first post should be updated to support the newly updated DLL.