NewsForumsCodeLogsGallerySpecsSearch

Child threads block forever on calls to LockMutex

Archives Forums/BlitzMax Bug Reports/Child threads block forever on calls to LockMutex

ima747(Posted 2010) [#1]
Personally seeing this on OS X

Check http://www.blitzbasic.com/Community/posts.php?topic=89975 for more details.

Essentially a child thread blocks properly when calling LockMutex on a mutex that has been locked from the main thread. However when the main thread unlocks the mutex the child never unblocks and resumes. LockMutex from the main thread however DOES block and then resume if a child has locked the mutex.

Using 
While Not TryLockMutex(mutex)
Wend
in place of LockMutex() in child threads seems to work.

Example by Rozek including wait time on the theory that the scheduler just didn't have enough time...
superstrict 

import brl.Threads

global Mutex:TMutex = createMutex()

  function ThreadFunction:Object (Data:Object)
    debuglog("Subthread:  started")

    repeat
      lockMutex(Mutex)
      debuglog("Subthread:  locked Mutex")
  
'     delay (1000)

      unlockMutex(Mutex)
      debuglog("Subthread:  unlocked Mutex")
  
      delay (1000)
    forever
  end function


debuglog("MainThread: spawning Subthread")
local Subthread:TThread = createThread(ThreadFunction,null)

delay(1000)

repeat
  if (ThreadRunning(Subthread)) then
    debuglog("MainThread: Subthread is running")
  end if

  lockMutex(Mutex)
  debuglog("MainThread: locked Mutex")
  
' delay (100)

  unlockMutex(Mutex)
  debuglog("MainThread: unlocked Mutex")
  
  delay (1000)
  pollSystem()
forever


He also has an example without the pauses in the above message thread.


ima747(Posted 2010) [#2]
Update: I've done some more testing on PC and it seem that the child thread thinks the mutex is always locked after it's been locked once from the main thread. Using the While() hack has the same infinite blocking as LockMutex().


Rozek(Posted 2010) [#3]
Well,

try to install the fix presented in http://www.blitzmax.com/Community/posts.php?topic=88462#1006351 and run the example again: on my machine, thread-switching works fine afterwards! (Personally, I lost this fix when I had to go back to earlier versions of BlitzMAX due to other problems and came back to the actual one using a fresh installation)

Thus, the reason for this behaviour seems to be the thread-insafety of the debugger (which may be fixed as shown)

Nevertheless, the fix (or something similar) should be worth being added to the "official" BlitzMAX distribution!


ima747(Posted 2010) [#4]
What fix in that thread exactly? if you're refering the the bbGCValidate fix looking at my module code it already has the getBlock call instead of testMemBit...


Rozek(Posted 2010) [#5]
No, I mean the other one (debugger.stdio.bmx), closer to the end of the thread


ima747(Posted 2010) [#6]
Tried the debugger.stdio.bmx from that thread and it works on windows now it seems... however the child thread still blocks forever on mac it seems.


Rozek(Posted 2010) [#7]
Logan,

which BlitzMAX and OS versions? (I am using BlitzMAX 1.38, MaxIDE 1.37 on a Mac mini Intel running Mac OS X 10.4.11)


ima747(Posted 2010) [#8]
After more testing it doesn't appear to be working on windows, it was just an OS specific compile in my source making me think it did.

Mac Mini core 2 duo running 10.6.3 <- while hack works around blocking

pc is running vista x64 SP 2 on an AMD X2 64 <- even the while hack doesn't allow it to continue

Blitzmax 1.38

Going to re-run the examples with every variant I can think of to my setup and see where it gets me.


ima747(Posted 2010) [#9]
Ugh, apologies. I had an unlockmutex that was never getting reached due to a bug in my code. Don't know if the debugger.stdio.bmx is needed in my case or not, but everything seems fine now on my end. I think Rozek did see a variant of this problem however through his test...


Rozek(Posted 2010) [#10]
Nothing special,

I just ran accross the problem, that "debuglog" is not thread-safe (without the modification of "debugger.stdio.bmx") nothing more - it's just that I forgot to re-apply the modification after having re-installed the current version of BlitzMAX)

Thus, there is nothing to be afraid of - Mutex's seem to work (beside the unforeseen result of "trylockmutex" under Mac OS X and Linux, which should be fixed in BlitzMAX 1.39)


ima747(Posted 2010) [#11]
TryLockMutex is quite sketchy for me on mac at the moment, currently just avoiding it, but looking forward to being able to use it