ogre 2.0 scene manager mRequestType flag is risky??

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
dummy_98
Kobold
Posts: 38
Joined: Sat Oct 31, 2015 7:12 pm
x 1

ogre 2.0 scene manager mRequestType flag is risky??

Post by dummy_98 »

http://file.allitebooks.com/20150510/Ef ... %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
restrictions:
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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

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

Post by dark_sylinc »

Hi.

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
http://preshing.com/20120625/memory-ord ... pile-time/
http://preshing.com/20120515/memory-reo ... n-the-act/
http://preshing.com/20120710/memory-bar ... perations/
http://preshing.com/20120913/acquire-an ... semantics/
http://preshing.com/20130922/acquire-an ... se-fences/
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

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

Post 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.
}
dummy_98
Kobold
Posts: 38
Joined: Sat Oct 31, 2015 7:12 pm
x 1

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

Post 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~!
Post Reply