seen that but it looks like it hangs there..
i'd suspect that we should not try to acquire the mutex a 2nd time in dropSendQueueJob()...
When I added dropSendQueueJob(), I changed the mutex so that it is recursive. dropSendQueueJob() should be able to acquire the mutex a second time from the same thread, as should zwSoftReset().
I'm not understanding. Are you saying the mutex is getting corrupted?
I see in the log it prints out "ERROR: Three dropped commands in a row, soft-resetting controller". In dropSendQueueJob()
this happens after the mutex is unlocked. Then there is the "Soft-resetting the Z-Wave chip" from zwSoftReset()
. Then I see the "Sending job..." which occurs from WriteSerialStringEx()
back in the main receiveFunction()
I was thinking the mutex was okay, otherwise the receiveFunction()
wouldn't be able to acquire it again before calling WriteSerialStringEx()
. But maybe, since this is all happening in the same thread, the mutex doesn't get unlocked as many times as it is locked - and then outside threads cannot add new things to the queue.
I was pretty sure there was a matching unlock for every mutex lock, but I'll take another look at the code again tonight. Hari, if you could take a look too I'd appreciate having a second set of eyes looking at the code too. It was from changeset 23385