pd->tid.set( (void*)_beginthreadex(NULL,static_cast<unsigned>(pd->stackSize),ThreadPrivateActions::StartThread,static_cast<void *>(this),0,&ID));
the method "pd->tid.set" sets the thread id, however via the startup function "ThreadPrivateActions::StartThread" that thread id is used (see further down the call hierarchy the line "int status = SetThreadPriority( pd->tid.get(), prio);".
Until now I never ran into any problem in debug or release builds, though. It seems that furtunately the tid.set method was executed always before the tid.get method in the startup code. However, this may make trouble in the furture. A simple solution is the following: just replace the line above with following two lines:
pd->tid.set( (void*)_beginthreadex(NULL,static_cast<unsigned>(pd->stackSize),ThreadPrivateActions::StartThread,static_cast<void *>(this),CREATE_SUSPENDED,&ID));
ResumeThread(pd->tid.get());
The trick is just starting the thread in suspended mode so the StartThread function does not get executed and we can safely store the tid by pd->tid.set. Then start the Thread by calling ResumeThread."
but I've moved this initialization into the constructor to make the code more managable.
CID 11686: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member cnt is not initialized in this constructor nor in any functions that it calls.
Non-static class member maxcnt is not initialized in this constructor nor in any functions that it calls.
Non-static class member phase is not initialized in this constructor nor in any functions that it calls.
code is clean and more mantainable.
CID 11676: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member cancelMode is not initialized in this constructor nor in any functions that it calls.
Non-static class member cpunum is not initialized in this constructor nor in any functions that it calls.
Non-static class member detached is not initialized in this constructor nor in any functions that it calls.
Non-static class member isRunning is not initialized in this constructor nor in any functions that it calls.
Non-static class member stackSize is not initialized in this constructor nor in any functions that it calls.
Non-static class member threadPolicy is not initialized in this constructor nor in any functions that it calls.
Non-static class member threadPriority is not initialized in this constructor nor in any functions that it calls.
Non-static class member uniqueId is not initialized in this constructor nor in any functions that it calls.
CID 11564: Unsigned compared against 0 (NO_EFFECT)
This less-than-zero comparison of an unsigned value is never true. "cpunum < 0U".
- compile errors on windows when compiled with UNICODE flag
- warnings for duplicate WIN32_LEAN_AND_MEAN. I think this should
better fixed by adding WIN32_LEAN_AND_MEAN to vcproj preprocessor
list."
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"
_beginthreadex() fails but OpenThreads still waits on the startup
Block before returning to the caller of OpenThreads::Thread::start().
This causes a deadlock. The return value of _beginthreadex() is
actually checked, but after the call to OpenThreads::Block::block() so
it is basically useless.
Attached is a fix to move the check for the return value of
_beginthreadex() before the call to block(), so that start() can
return to the caller with a non-zero error code. This solves the
problem for me."
order, and not in the order they are listed in the constructor. To
avoid possible trouble, gcc warns about this. Attached modification
fixes the initializer order to silence this warning."
Also, there was also a small bug in osgDB's CMakeLists.txt that was causing an error when I tested with CMake 2.4.4.
IF(${OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX} STREQUAL "quicktime")
was changed to
IF(OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX STREQUAL "quicktime")
"
working with that thing.
This is what was missing so far:
Make win32 threads behave like the posix implementation when setting thread
cpu affinity. That includes avoid setting thread affininty on a non running
thread. Set that once it is running."
On OpenThreads win32 implementation we unconditionally unlock a mutex in the
destructor. That happens even if the mutex was not locked before.
When running a osg application within microsofts application verifier, that
software checks tells me that we should not unlock an unlocked mutex.
When I look at the posix threads mutex implementation, which does no unlock in
the destructor and where it is illegal to destroy a locked mutex, I conclude
that it is not needed for an OpenThreads::Mutex to do that unlock in the
win32 Mutex destructor.
Thus this patch based on rev 9358 removes that additional unlock in the win32
mutex implementations destructor."
consider these initial cpack support scripts. It is hidden behind a
BUILD_PACKAGES option so won't affect the normal user. The submission
1) set the COMPONENT attribute on all cmake install commands.
COMPONENT names are according to
http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging
2) provide cmake script and a template for creating CPack
configuration files. It will generate target for creating packages
with everything that gets "installed" (make package on unx, project
PACKAGE in MSVC) plus targets for generating one package per COMPONENT
(i.e. libopenscenegraph-core etc.).
I have temporariliy uploaded some examples to
http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing
If this submission makes it into svn we can develop it to generate
rpms, installers for windows and mac (I know at least J-S don't like
these but there may be others who do ;) and even DEBs (not sure if we
can make them "ubuntu-ready" but they eventually may - at least we
could put a deb on the website)"
"
and a later post the same osg-submissions thread:
"it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds."
And another post from Blasius on this topic:
"I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.
In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))
should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b))
The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I attached a corrected version.
Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere.
OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that.
"
This change has been done to make it easier for OpenSceneGraph users to check out the svn via https
without any conflicts introduced with a http externals.
