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().
seen that but it looks like it hangs there..
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() loop.
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