Page 1 of 1

ogre 2.0 scene manager mRequestType flag is risky??

Posted: Thu Nov 26, 2015 4:13 am
by dummy_98 ... %20C++.pdf

275 page item 40 :
As a general rule, compilers are permitted to
reorder such unrelated assignments. That is, given this sequence of assignments
(where a, b, x, and y correspond to independent variables),
a = b;
x = y;
compilers may generally reorder them as follows:
x = y;
a = b;
Even if compilers don’t reorder them, the underlying hardware might do it (or might
make it seem to other cores as if it had), because that can sometimes make the code
run faster.
scenemanager's mRequestType depend on order for thread safe.

mRequestType need declaire volatile???

oops ,i check more
volatile can't solve order , too

only solution is std::std::atomic ............

declaring valAvailable as std::atomic ensures that our crit‐
ical ordering requirement—imptValue must be seen by all threads to change no later
than valAvailable does—is maintained.
Declaring valAvailable as volatile doesn’t impose the same code reordering
volatile bool valAvailable(false);
auto imptValue = computeImportantValue();
valAvailable = true; // other threads might see this assignment
// before the one to imptValue!
Here, compilers might flip the order of the assignments to imptValue and valAvail
able, and even if they don’t, they might fail to generate machine code that would
prevent the underlying hardware from making it possible for code on other cores to
see valAvailable change before imptValue.
These two issues—no guarantee of operation atomicity and insufficient restrictions
on code reordering—explain why volatile’s not useful for concurrent program‐
ming, but it doesn’t explain what it is useful for. In a nutshell, it’s for telling compilers
that they’re dealing with memory that doesn’t behave normally.

Re: ogre 2.0 scene manager mRequestType flag is risky??

Posted: Thu Nov 26, 2015 3:14 pm
by dark_sylinc

mRequestType is protected by the mWorkerThreadsBarrier->sync() call.

Volatile isn't needed because the compiler can't assume mWorkerThreadsBarrier->sync() won't need to read or write from/to mRequestType. Essentially it acts as a compiler memory barrier.
HW atomicity isn't needed because the sync() call will either end up using an interlocked instruction (which triggers a hw memory barrier) or directly a kernel synchronization primitive to enter a waiting mode (which also triggers a hw memory barrier).

See ... pile-time/ ... n-the-act/ ... perations/ ... semantics/ ... se-fences/

Re: ogre 2.0 scene manager mRequestType flag is risky??

Posted: Thu Nov 26, 2015 4:00 pm
by dark_sylinc
I took a small glance at the book, and the fact that it recommends using auto as much as possible, even of a fu**ing literal is an insta-ban on my list. Even if it comes from Steve Meyers.

From my post
One of our fears is that contributors will start using auto everywhere. Auto looks awesome to get rid of typing 8 extra letters, but it's very horrible when you have to analyze code written by someone else and you can't quickly see what the variable's type is, or you don't have an IDE to help you.
Auto is useful inside templates, since the variable type may not be known until compilation or specialization, or when the syntax inside the template gets too complex. However using auto outside templates (or everywhere!) is an abuse.
It can even introduce subtle bugs: e.g.

Code: Select all

auto x = 7.0; //This is a double
auto x = 7.0f; //This is a float
auto x = 7.; //This is a double!!!
auto x = 7; //Is this an int or a uint?
The first one may be intended to be a float, but the 'f' was missing.
The third one may be supposed to be an integer, but the extra '.' made it a double. Easy to miss.
The fourth one is the worst kind. Signed integer overflow is undefined behavior. Unsigned integer overflow is well defined (wraps around). This can have unforeseen consequences:

Code: Select all

auto x = myInteger; //int myInteger = 262144; causes undefined behavior as result should be 68719476736, but doesn't fit in 32-bit
if( x * x < x )
//The compiler may optimize this away. Which wouldn't happen if 'x' were unsigned.

Re: ogre 2.0 scene manager mRequestType flag is risky??

Posted: Thu Nov 26, 2015 5:27 pm
by dummy_98
thanks for answer.

i used a little about 6-7 years ago, try to use ogre 2.0 second time.

Clearly, the Ogre 2.0 looks like rather a different engine, Unlike previous versions.

it have very good performance , looks Strong......
Recently impressed by the Ogre 2.0 design.

i like it.

therefore , This time my project, i decided to use the Ogre 2.0

only.... I was a little bit worried that thread is difficult to understand and produce difficult to catch bugs.

In other words, The stability of the engine a little worried.

dark_sylinc,You seem to be a very good understanding about the thread.

but if ogre engine have bug, Common user seems hard to find(report) bugs because thread and SIMD friendly code is written in a low level.

so... i hope you Continuously to please check to stability Through a code review .

Keep up the good work~!