Game Development Community

Why is MutexHandle::lock() non-blocking by default?

by Lateral Punk · in Torque Game Engine · 06/02/2006 (7:54 pm) · 5 replies

Just noticed something extremely weird. MutexHandle::lock is defined as such:
bool lock(void *mutex, bool blocking=false)
   {
      AssertFatal(!mMutexPtr, "MutexHandle::lock - shouldn't be locking things twice!");
      
      bool ret = Mutex::lockMutex(mutex, blocking);

      if(ret)
      {
         // We succeeded, do book-keeping.
         mMutexPtr = mutex;
      }
      
      return ret;
   }

but then the code for Mutex::lockMutex() is defined as such:
static bool lockMutex( void *mutex, bool block = true);

What is the handle set to blocking false and the actual mutex set to true by default? It seems inconsistent in my opionion. And definitely gives unexpected behaviour for first time users. I put mutexes around my code, and two threads were still going in. I was at total lost, until I saw that the handle by default is set not to blocking. Am I missing something here?

#1
06/03/2006 (6:46 am)
It's probably just a typo. I added the blocking flag to Mutex since I needed non-blocking mutexes and the old behavior was to always block. At that point MutexHandle didnt exist yet, so when Ben wrote MutexHandle he probably just overlooked the default value for Mutex::lockMutex().

If you change the default behavior, then its a good idea to double check all existing uses of it. MutexHandle came about to simplify a lot of code in the sim and console so it's used quite a bit.

T.
#2
06/03/2006 (11:11 am)
Thanks for the information. I'll probably just keep the "typo" in for backwards compatibility. Or do you think this will be addressed as a bug?
#3
06/04/2006 (11:34 am)
This is a typo. It should block by default, IIRC.

#1635.
#4
06/04/2006 (11:42 am)
So Ben, wouldn't that mean that whereever you were using MutexHandles currently in 1.4 wasn't really resulting in the behaviour you expected (ie. threads were not blocking when required and it wasn't really producing thread-safe code?).
#5
06/04/2006 (2:17 pm)
@LateralPunk,

Not neccessarily. I've hammered on the thread code a lot and have already fixed a few issues that came up post-1.4. If this was a problem, I'd probably have found it by now. Of course, that doesnt mean that it definately isnt a problem, so it should still be double checked.

T.