connorl309
commented
1 year ago We might be able to use the timeout options for mutexes that Micrium allows, and in our wrappers/calls to assertOSError we can print some debugging info if we get a timeout error (i.e. there was a deadlock but the timeout prevented it from fully locking up)
For deadlock prevention: Bottom of page 7: https://pages.cs.wisc.edu/~remzi/OSTEP/threads-bugs.pdf also: https://jenkov.com/tutorials/java-concurrency/deadlock-prevention.html For not detecting when you're not using a mutex when you should: You can read the code by hand (maybe give each shared resource a ticket and have some people read over the code and wherever it is used, make sure it is locked) You can try implementing something like this (or find a newer approach. This paper is from 2005): https://www.cs.utexas.edu/~rossbach/cs380p/papers/yu05sosp-racetrack.pdf You would probably implement this by adding some instrumentation to RTOS_BPS functions and by wrapping accesses to shared variables with a macro that adds some instrumentation. I can write an example if you want. You can also try and see if you can find a framework for detecting race conditions that works with micrium (or pthreads for the simulator)