Newton with std::thread and atomics

[Julio Jerez]

I see if I add support for C++ threads this weekend.

[aitzolmuelas]

That's great! It's awesome that you are so active in maintaining/developing Newton, so thanks.
The sample I was trying to compare pthreads vs c++11 is the one names "Simple Box Stacks". I have re-tested the multithreading version using spinlocks and it doesn't stall anymore :$ it might have been something else altoghether... Anyway I'll keep investigating, I'm downloading the VS concurrency visualizer now (thanks for the tip, I didn't know this tool existed )

[aitzolmuelas]

Brief update, I haven't had much time for trying the profiler, but here's a comparison of what I've got so far:

Using pthreads semaphores

pthread_semaphore.jpg (86.38 KiB) Viewed 10641 times

Std threads 'yielding spinlock' as semaphore

yielding_spinlock.jpg (86.79 KiB) Viewed 10641 times

I'm not quite sure how to interpret it: total update time for physics seems slightly lower with spinlock, but then running time of each thread seems to increase (???) and framerate drops when using this spinlock.
Anyway, I have to disable multithreading for some tests on another platform (multithreading crashes there for some yet unknown reason) but I will stay tuned to this thread to see how progress goes. Hope I'm not being too confusing... and thanks again for all.

[Julio Jerez]

so look like std thread seems better results but it is not really.
This is what I was trying to say before, a spin lock will try to grab the CPU at the expenses of penalizing every thing in the system.
the worse thing for scheduling thread is to use Spin Look or heavy mutexes, it must use Semaphores.

that result look is awesome, more reason to make a move.
I am sure that std Thread most support Semaphores. all OS support them.

also there is something you have to consider.

in some archteture a spinlock will cost a lot more, because the wasy the cache works, some system have local cache, shere memory, an so on,
it may be that one spin lock that look like one instruction in a system with local non shared memore, may cause the a full Page of 4 k to be copy from case to second lever cache all the way to system memory.

another thing that is unpredictable is how many high priority thread are running in the system,
example a sound, a input, a disk read, etc will preset a thread.
the best one can do is to have some option and test the best for the system.

Multreading programing actually *, it is a lot of trial and error.

finally remember that that box stack test is actually a tress test.
Game are go going around making stack of boxes for sake of doing that.
stack of bodies is hard on the work thread because it usually generates unbalanced loads.

[aitzolmuelas]

I will try to keep it in mind (multithreading is indeed a lot of trial and error). In my particular case I have control over the threads present in the system and their priorities (console dev) but of course that cannot be expected in the general case.
I read that, while std::threads do not support semaphores directly, they can be implemented easily using conditional variables (which it does support). I have not tried this yet but I may give it a go today.

[aitzolmuelas]

Google be blessed, turns out making a semaphore out of a cond_var and a mutex is pretty simple:

Code: Select all

class dgSemaphore
{
   public:
   dgSemaphore ();
   void Wait();
   void Release();

   private:
   std::condition_variable m_cond;
   std::mutex m_mutex;
   unsigned m_count;
};

dgThread::dgSemaphore::dgSemaphore ()
{
    m_count = 0;
}

void dgThread::dgSemaphore::Wait()
{
    std::unique_lock<std::mutex> lock( m_mutex );
    m_cond.wait( lock, [this](){ return m_count > 0; } );
    --m_count;
}

void dgThread::dgSemaphore::Release ()
{
    std::unique_lock<std::mutex> lock( m_mutex );
    ++m_count;
    m_cond.notify_one( );
}


I tried it a bit with the box stack demo and it looks to be working exactly like the pthreads semaphore (performance-wise, at least, framerates, thread times and load looks pretty much the same, unlike with spinlocks). Hope this helps

[aitzolmuelas]

By the way, credit goes to http://cpprealm.blogspot.com.es/2012/08 ... sting.html (I simply used the wait call that takes an argument to 'clean' the while loop, otherwise it's identical and performs the same).

[Julio Jerez]

Oh that must be it, cond_variable

and the is the difference, a semaphore is basically an atomic, variable that is incremented, an function wait on single object know about it.

Mutex are system level call, that cost from hundred of thousand to million of clock cycles, each time two one or more cores access it.
I see he still uses a Mutex, and it should not have to use mutex at all.

instead of the Mutex it should use
AtomicAdd (m_count, 1) and atomicAdd (m_count, -1)

but I see that is the solution, cool.

[aitzolmuelas]

Yes, that's what I meant: there SEEMS to be no difference regarding performance when comparing pthreads vs this custom c++11 semaphore (and the test case is the box stacks demo, which as you mentioned is heavy load and very imbalanced). Which gets me thinking that this custom implementation might not be that different in the inside from a semaphore: it looks as expensive as you think, but from what I have read around most current mutex implementations use an atomic to avoid the system call if the mutex is not owned by any thread.
But again I am not a multithreading expert (yet, I hope to improve ;P) so this is just my shallow analysis.

[Julio Jerez]

but from what I have read around most current mutex implementations use an atomic to avoid the system call if the mutex is not owned by any thread.

yes that is correct, but that precisely the problem with Mutes, mutex does get hit by many threads form nay cores. Mutes where probable good before the age of Multi cores systems.

you can actually step in assembly code in a mute call and see that it doe sin fact implement and atomic, but when the atomic is hot by more than one thread it goes to system kernel call.
This is very misleading because when you have thread that take very loads on CPU work the mute very rare get hit by more that tow thread.

when you have a job pool whet there are many thread running on many cores that all hell brae lose and almost all the time is spend in the mutex.

I have not idea why Mutes are so Dreadful, and Semaphore aren't, but Mutes are awful at list on widows and Max systems.

[aitzolmuelas]

Yes, I agree with those facts about mutexes: however, if you look closer at this semaphore case, the mutex is NOT locked for the whole duration of the wait (the wait operation on the cond_variable actually unlocks the mutex) only for a brief moment during the call, so in the end there is NOT a lot of competition over the mutex. This is a very particular use-case of mutexes that actually behaves a lot like semaphores (after all semaphores must also eventually resort to system calls, otherwise I don't understand how they could perform a non-busy wait). I guess that explains why performance is indistinguishable from using semaphores (at least from the numbers I am getting, although I still want to do some more heavy load tests).

[aitzolmuelas]

Also, as further check, I have just been looking into the pthreads32 implementation of sem_wait() and it does indeed use a mutex just like the c++11 implementation.

[aitzolmuelas]

Also one thing I just realized: the m_count variable in the implementation I suggested is protected by the mutex, but it will be accessed within a while loop (internally in cond_variable::wait() ) from different threads, so maybe it should be marked as volatile?

[aitzolmuelas]

After investigating a bit the consensus seems to be that no, it should not be volatile. Plus, the code seems to work perfectly without the volatile, and the internal implementation of semaphores in the pthreads32 wrapper does not use volatile for its counter, o I assume that is the correct approach.
Guess I ended up answering my own question