LockMutex never continues in child thread...
BlitzMax Forums/BlitzMax Programming/LockMutex never continues in child thread...
| ||
| I'm just getting started with bmax's threading system, and making surprisingly good progress so far, but I have hit a snag. It seems that in my child threads LockMutex blocks like it should, but when the mutex is unlocked the child never resumes... illustration: Main thread spawns child thread mt: locks a mutex to prevent all graphics access ct: attempts to lock graphics access, but it's already locked by mt, child blocks mt: finishes with graphics, unlockes graphics access mutex ct: ... nothing happens mt: locks graphics, does stuff, unlocks, etc. eventually runs out of things to do so just kicks a WaitSystem() so it doesn't idle in a loop wasting processor time ct: ... (guess: got bored is now finger painting) TrLockMutex however works fine. I have a different type of child thread that does some loading, then keeps querying the graphics lock with trylockmutex until it becomes open, does it's graphics stuff and unlocks, and all is well there... but it seems to me that lockmutex is supposed to prevent me from having to do exactly that... |
| ||
So if you do nothing except replace LockMutex calls in the thread with the following it works?While Not TryLockMutex(mutex) Wend |
| ||
| Yup. my code was doing some other things, but I just replaced my other workaround with that (much simpler) approach and it works... |
| ||
| I don't know if I was clear before or if it matters, but this is only in child threads, the main thread blocks properly with LockMutex() and resumes properly. but lockmutex() in a child thread causes the thread to block forever. |
| ||
| OK, then this must be a bug. Which OS do you use? |
| ||
| This is on OSX, haven't done any threading testing on windows yet, but it does compile and seems like it should run there... |
| ||
| Hmmm, I am heavily using lockMutex, unlockMutex, tryLockMutex to synchronize main and subthread under Mac OS X 10.4.11 - without any problems (besides the fact, that tryLockMutex works differently than described!) You might have been bitten by that issue as well... Have you seen my other thread on that issue (see http://www.blitzmax.com/Community/posts.php?topic=89911)? Mark will correct this bug in the next version |
| ||
| Logan, you are right! When trying the following example superstrict
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")
forever
end function
debuglog("MainThread: spawning Subthread")
local Subthread:TThread = createThread(ThreadFunction,null)
delay(100)
repeat
lockMutex(Mutex)
debuglog("MainThread: locked Mutex")
delay (1000)
unlockMutex(Mutex)
debuglog("MainThread: unlocked Mutex")
forever
I only get output from the main thread!Strange! |
| ||
| Strange, I modified my example a bit to give the scheduler a chance to switch between threads - but with no success! Here is the current example: 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
Despite all the "delay" calls (and even "pollSystem") the subthread never writes anything onto the output area.YOU SHOULD DEFINITELY FILE A BUG REPORT! Surprisingly, my "real" applicaion works fine with all its "lockMutex"/"unlockMutex" calls - dunno what's going on here... |
| ||
| You are probably looping so fast, that the subthread is not getting a chance to run. You are unlocking and then locking again instantly. |
| ||
| Marcus, no - that's why I have the "delay" calls in my example - and "delay" *should* do a context switch, otherwise the whole multi-threading stuff would be useless |
| ||
| re: tastmaster That's what I thought at first, but literally the main thread runs out of things to do so it just idles (calls waitsystem() to let the OS do whatever rather than just burning an infinite loop) so I know it's not making ANY lock/unlock calls, it's just waiting for the system to toss up an event. I had to strip threading out of my program temporarily to get some other things sorted out (wanted to make sure there was no overlap) but I'm going to put it back in now and keep digging. I may have been forgetting to unlock at some point, however that should have stopped the TryLock's as well so I don't think that was the culprit... as the thing would have just remained locked forever if I forgot to unlock and nothing would have worked... we'll see. Thanks Rozek for the proof of concept, should help with bug reporting. I'll post on the bugs board with a link back to this thread and your example. |
| ||
| Logan, take care of the "trylockmutex" "bug" under Mac OS X (and Linux, according to Mark). If you aren't yet aware of that problem, "tryLockMutex" may only PRETEND to work - but it actually isn't! |
| ||
| Thanks for the heads up. I was getting some crashing when using that on occasion but as I'm just getting my feet wet with threads, and my current project is getting to the "bulky" stage at this point, I was chalking it up to my own errors (still likely) but it's good to know it might not be ALL me :0) |
| ||
| Bug Report at http://www.blitzbasic.com/Community/posts.php?topic=89978 |
| ||
| I did a little more poking in my program and it seems on windows that even the While hack workaround doesn't work on windows. it always thinks it's locked once it's been locked by the main thread. |
| ||
| Logan, I might have found a solution - see at the end of your bug report (i.e. http://www.blitzmax.com/Community/posts.php?topic=89978) |
| ||
| abandoning this thread and switching to the bug report thread. |
   |