This appears to be an issue only with the HotSpot port to SPARC/Solaris
- I was unable to locate any instances of this in the x86/Win32 workspace.

Consider the following code :-

{
   MutexLocker(Terminator_lock);

   // do Something

   // end of block
}

Notice that MutexLocker is not bound to a variable - not sure how the
C++ standard handles this but the C++ compilers seem too.

With the SPARCworks compiler the constructor runs at the begining
of the block and the destructor runs at the end of the block as
expected.

With the GNU g++ compiler the constructor runs followed immediately
by the destructor - this means the mutex is not held during
execution of the block leading to undefined behaviour.

A licensee has reported a problem in WatcherThread::watcher_main
(thread.cpp) where a MutexLockerEx object is used without it being
bound to a variable - this means the mutex does not behave as
expected. This is not an issue for the x86/Win32 workspace because
it used a MutexLock that is bound to a variable.