Newton with std::thread and atomics

[Bird]

i am certainly no expert in c++c11 concurrency but mainly as an exercise I made versions of dgThread, dgMutexThread, dgAsyncThread and dgThreadHive using std::thread tools instead of Pthreads. Everything seem to be working fine on my system but I've only tried out on a PC complied with vs2013 Express.

If you want to try it out you should be able to just replace the existing files with the ones included. dgTypes.h has the std concurrency header files and implements dgThreadYield () with
std::this_thread::yield();

-Bird

[AntonSynytsia]

Can you tell the advantage of std::threads over Pthreads?

[Julio Jerez]

I can see one advantage, and that is the Pthread is not maintained for window.

The version of pThread I use for window has a couple of Bugs that I had to fix myselft, and it is very poorly implemented.
I does not let you override the memory allocations, and is does lot and lot of allocation, the in the long run cause fragmentation.

The only advantage of using pThreads, and the is a big one, is that it provides cross platform compatibility.

does you implementaion run on OS X? Bird

[Bird]

I can see one advantage, and that is the Pthread is not maintained for window.

The version of pThread I use for window has a couple of Bugs that I had to fix myselft, and it is very poorly implemented.
I does not let you override the memory allocations, and is does lot and lot of allocation, the in the long run cause fragmentation.

The only advantage of using pThreads, and the is a big one, is that it provides cross platform compatibility.

does you implementaion run on OS X? Bird

I haven't had much time for testing on the Mac, but yes, it seems to be working fine on OSX

-Bird

[Julio Jerez]

Ok I took a look and the implementation everything seem very good with one exception, there Semaphore is emulated with a mutex in this function.

Code: Select all

inline void dgThread::dgCriticalSection::Lock()
{
   #ifndef DG_USE_THREAD_EMULATION
      #ifdef DG_USE_MUTEX_CRITICAL_SECTION
         m_mutex.lock():
      #else
         while (m_mutex.exchange(1)) {
            std::this_thread::yield();
         }
      
      #endif
   #endif
}

although they do the same job, the do it in a very different way. Semaphore are designed to be real time object while mutex aren't
a semaphore remove a thread for the circular list of thread that the OS is running.
Mutex do not do that, the system is still visiting the tread, this is not different than using Sleep (0) or Yield with some atomic to do the suspension.

in the loop the system is still calling the loop and doing all the work of this_thread::yield(); wick is a lot, the result is that the tread code has those random spike each time '
the Mutex coge in an out of the system, a Semaphore the thread is not suspended, it is simple removed form the list of thread the system gives time slices.
the m_mutex.lock(): will never come back because the OS never run the tread at all, it is some other thread that has to put the tread back but Semaphore Release.

I will see if the semaphore are supported, because I would love to get rid of the pthread dependency.

Semaphores are supported native in Window and Linux, an dI though OS ten did no but after some research I found out that OSX in fact supported semaphore, they just make them uniquely name,
meaning each one have to have a unique OS name, other wise the OS give you a instance of the and existing one.
I did this in this functions

Code: Select all

dgThread::dgSemaphore::dgSemaphore ()
{
   #if defined (_MACOSX_VER) || defined (IOS) || defined (__APPLE__)
      char temp[256];
      static int semID = 1;
      m_nameId = semID ++;
      sprintf (temp, "%s%d", DG_SEMAPHORE_NAME, m_nameId);
        sem_unlink(temp);
      m_sem = sem_open(temp, O_CREAT, S_IRUSR | S_IWUSR, 0);
   #else
      sem_init (&m_sem, 0, 0);
   #endif
}

I am sure Semaphore C++ 11 must have them, or even should be available because there are use a lot in window an Linux.
using Semaphore instead of a Mute to emulate them make a bug different on how smooth the thread switch operates.
It took me a long time to figure out why the thread was never smooth an dis was because originally I did the same you did. and I always had those spikes.

I will do more research to see if I can figure out how to get the Semaphore, because would love to get rid of the pthread dependency in windows. plus I also love the standardization of Atomics.
notice that windows is the only OS that do not support then natively.

The other problem is how well accepted is C++ 11. I still have people how build newton with VS 2008.
I myself use VS 2010 maybe it and this is VS 2013 minimum?

[FSA]

Why should you support those old versions? This doesn't make much sense. I use the highest version possible. But oftens it is the case that I can't use 2013 because of libs that just support 2012 and lower Of course buying a new license may be expensive. But why should you have more work with so many projects for different versions? If Newton wouldn't be free than it would be ok to support older versions. But it is "open source"

[JoeJ]

Personally i don't dare to use c++11 yet, although it has the feature i've always missed (writing small functions inside another).
Here's a support table (does not help here but it looks a bit empty in general):
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

I'd keep both versions for a while if possible.

[BeRo]

The Newton_withstd_threads.zip attachment seems to be a corrupt zip file.

[godlike]

If you use semaphore as a spinlock (bussy wait) then there is a way to do that using atomics. See a super simple implementation here: http://anki3d.org/spinlock/

Also, if you don't like C++11's thread library you can check what I've implemented for my needs. It's a minimal thread library (spinlock, mutex, thread, condition variable, barrier, threadpool) with windows (windows vista and above & not tested excessivly) and POSIX support. It uses C++11 atomics though but that fixable. Files here:
https://github.com/godlikepanos/anki-3d ... l/Thread.h
https://github.com/godlikepanos/anki-3d ... Thread.cpp
https://github.com/godlikepanos/anki-3d ... dPosix.cpp
https://github.com/godlikepanos/anki-3d ... indows.cpp

[Colin]

Boost provides a semaphore implementation in Boost.Interprocess; documentation here:

http://www.boost.org/doc/libs/1_57_0/do ... semaphores

It's a header-only library BTW

[aitzolmuelas]

Hi, am currently attempting to swap our current physics engine for Newton in the game we are currently developing (in the company I work for). It must work on platforms for which we do not have pthreads support, but we do have c++11, so I was trying that approach: so far I have run into the mentioned problem with the semaphore implemented with atomics and yield (it stalls a lot depending on how many threads and with what priorities are running in the game). I will keep investigating if there is any portable way to do semaphores, and also keep an eye on this forum.

[aitzolmuelas]

Also, I have been able to leave the pthreads implementation alongside c++11 by using macros, and the code does not get very dirty, so it's doable, in case backwards compatibility is desired

[Julio Jerez]

I am curios to know what Platform does not support pthread.

My understanding was that pThread interface is the standard for Unix, bsd systems.
It was my understanding that All Unix, OSX, Iris system support pthread natively.
Window was the rouge OS that did not.
can you tell me the OS?

also in the at post about faking Semaphore with atomics, that a really, really bad idea.

I try that some many time when I was doping my goring pain learning mutjhredingg programming.
The bets you can get with atomic is a spin lock with a three yield, buy must thread sleep or yield and very very duty kernel calls that cost ten of million of ticks.
Semaphores are the lithered weight object that out can use for thread syconronation,
Spin Lock are usefull or extreme tight loop but not for thread blocking.

[aitzolmuelas]

Mainly for next-gen consoles (not sure if I am allowed to go into any more detail due to NDA): the truth is pthreads might be an option by writing a wrapping layer similar to the one in windows, but it just seemed easier (and quicker) to do the c++11 version.
As a curiosity about the 'semaphores with atomics' thing, when I run the Newton samples with this implementation they seem to run slightly faster (4ms update vs the 5ms I was getting with the original implementation) so again I guess it has a lot to do with thread priorities and scheduling (but I suppose the proper semaphore way is still the most adequate in the general case).

[Julio Jerez]

not it is no priority, thrust me it the semaphores. Pthread wrapper is in fact a very thing layer on top of the native win32 thread interface. what do is no different than what different window would do.
and about 90% of all function are inlined, so the overhead is near zero.

I also recently replace some sleep with single spins without sleep. This in the cases where the function is primarily an atomic write, or a very short critical section.

Critical section are also expensive if it happen that tow or more cores hit the. the second goes in to expensive kernel call that cost form hundred of thousands to million of clock.

The way I test this is by using Visual studio concurrency analyzer. you can actually see the effect of a semaphore VS a full mutex, of a spin lock.

you say the scene run on 4 to 5 MS, what kind of scene are we talking about?