while in an else clause. When if is true the phase changes and the
while condition will always by false, so might as well put the while
in the else to skip the check. There's also a benefit to having the
code logic similar between platforms.
"
Barrier operations. The error is with atomic operations in the
win32 condition implementation. The attached sample program will
reliably trigger with as few as three threads and a dual core system,
though sometimes it will take 65,000 iterations.
2.8.1 was the base for these changes
Win32ConditionPrivateData.h
Win32ConditionPrivateData::wait does two operations to decrement
waiters_ then read, when InterlockedDecrement decrements and returns
the value in one operation. The two operations allows another thread
to also decrement with both getting 0 for an answer.
Win32ConditionPrivateData::broadcast is using waiters_ directly
instead of using the w value read earlier, if it was safe to use
waiters_ directly there would be no need for InterlockedGet or w.
overview of deadlock in barrier with three threads
one thread in broadcast, 2 threads in wait,
release semaphore 2, waits on waiters_done_
both threads wake, decrement waiters_, get 0 for w,
<logic error here>
one calls set waiters_done_,
broadcast thread comes out of waiters_done_,
other thread calls waiters_done_, (which leaves waiters_done_ in the
signaled state)
<sets the trap>
broadcast thread returns releases mutex, other threads get
mutex and also return,
next barrier, first two threads enter wait, one goes to broadcast, release
semaphore 2, skips waiters_done_ as it had been released last time
returns, processes, enters the barrier for the next barrier operation
and waits,
three threads are now in wait, two have the previous barrier phase,
one the current phase, there's one count left in the semaphore which a
thread gets, returns, enters the barrier as a waiter, sleeps, and the
deadlock is completed"
GraphicsWindowCocoa-implementation, which enhances multithreaded
stability, it ensures that modifications to the size of an openglcontext
is done only from one thread.
"
Selection is now just a typedef of osg::MatrixTransform, and is deprecated
CommandManager is shell class that just sets values directly on Dragger, and is deprecated
Dragger now has list of DraggerCallback that takes over the roll of tracking changes to the Dragger, and
allows users to track the dragger in any way they wish.
Dragger now has a convinience method making MatrixTransforms track a dragger.
Selection and CommandManager are no longer required for use of osgManipulator and are kept around for backwards compatibility.
dependent on the complexity of the geometry. For complex scenes this
meant that it looked like you were "throwing" the display into molasses.
For simple geometry things get over-excited once thrown.
The fix is to factor in the frame rendering time to the caluclated
motion. I've implemented this for rotation and panning.
Now when things are thrown they maintain a rate very close to what was
happening when the mouse button was released."
Therefore I have changed all the occurances of atof by asciiToFloat or
asciiToDouble.
I believe that it is safe to do so at least for all the plugins.
Included here are also asciiToFloat conversion of environment variables. One
might argue that these should be locale dependent. But IMO these should be
set and interpreted by osg independent of the current locale.
"
