Trolling The Spring-MT Goes Into The Wrong Direction Thread

[Andrej]

It cannot even be done, as your assumptions are totally wrong. Mutexes simply do not work like that. Threads that want to lock a mutex end up waiting in a queue-like fasion and will begin running immediately once the lock is released.

no u

From class mutex boost documentation:

If boost has detected thread support in your compiler, the mutex class will map to a CRITICAL_SECTION on Windows or a pthread_mutex on POSIX.

Ok so pthreads on linux and pthreads on mingw.

From POSIX spec page on
pthread.h / pthread_mutex_lock:

If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy shall determine which thread shall acquire the mutex.

This guy has something on scheduling policy (section named "5 Linux" is about pthread):

The default scheduling policy is SCHED_OTHER, which is the default Linux scheduler.

Which i suppose means using the
traditional scheduling (look at the "absolute scheduling as Roman cultural invasion" analogy WTF)

The dynamic priority sometimes determines who gets the next turn on the CPU. Sometimes it determines how long turns last. Sometimes it determines whether a process can kick another off the CPU.

So basically boost and other pthread mutex rehashes behaviour is defined as LOL SO RANDUMB
and if two threads try acquiring and releasing mutexes as fast as possible it is practically guaranteed that they will go out of order especially with other OS processes or threads running and screwing the scheduling.

You can ofcourse use some cheesy mutex implementation like with a synchronized queue.

Code: Select all

on lock:
  if queue is empty: insert thread into queue & go
  if queue is not empty: insert thread & wait until the thread is in 1st position in queue then go
on unlock:
  remove 1st position from queue
(actually i think Jk's set-a-bit-when-waiting thing behaviour is same as this in case threre only 2 threads)

You still need a mutex for synced queue so you get lock contention or whatever that is called
but instead of render thread thread being able to go through multiple times in a row access will be interleaved.

Over 396 Ewoks died to bring you this information.
Also clearly we shouldbeable to post in the dedicated dev forum, cleaning it up from spam would then distract neddie from writing random flame posts, forum policies and thread lockings thushaving an effect infinetimally superior to say the global moderator nomination thread.
Also i ran out of space for thread subject 60 chars is way too little ;_;

[smoth]

I think you posted in the right place but aren't you one of the guys doing engine work or some shit?

I don't want myself or other content devs fucking up the dev discussion. Only people actually deving the engine should have acess to that chat. I think posting here for the rest of us is fine. don't want to open the floodgates of this shit community on the poor devs. We content devs have enough I don't want engine devs dealing with this lot of human excrement.

[Argh]

After reading the cites, I get what they're arguing about, but I think both sides of that coin are irrelevant.

We aren't going to want to use stops and semaphores, because we aren't going to want to use a single data location. The needs are incompatible with the design; CPUs sharing a common data location and making sure the fat kid won't starve are impossible to fully reconcile with a system where if sim can't complete fast enough, games desync, whereas everything short of sim can go to hell for quite a long time without seriously effecting anything at all.

IOW, keeping it all in one place is, no doubt, easier. But it won't actually solve much and it probably won't even run a lot faster.

[smoth]

um no argh.

[zerver]

but instead of render thread thread being able to go through multiple times in a row access will be interleaved.

OK, maybe not a queue then, but since we have only 2 threads here it makes no difference. The point is that the draw thread cannot create a livelock-like state by locking the mutex too frequently. If the sim is waiting, it will be allowed to run once the lock is released.

The important factor is the percentage of CPU time that the draw thread keeps the lock. This amount will deprive the simulation of an equal amount of precious execution time.