It's going to be hard and probably unfeasible to keep track of all the OS / external conditions to implement a real deadlock-prevention algorithm on a real application. Modern OSes (when we're not talking about RT-aware systems) prefer not to implement such algorithms due to their overwhelming complexity and expensiveness.
In other terms you can get away from a Windows deadlock, in the worst case, with a simple reboot. And given how many times this happens it isn't deemed a huge problem in the desktop OSes market.
Thus I recommend to write a simple test case with a dummy application that will either
- Serve your purpose
- Allow you to know exactly what's being used by your application and let you manage the complexity
As a sidenote: applications like notepad.exe or similar are not real-time processes even if you give them "Real Time" priority in the Windows task manager (and not even soft-real time). Real real-time processes have time constraints (i.e. deadlines) that they MUST observe. This isn't true in any desktop OS since they're just built with a different concept in mind (time sharing). Linux has some RT patches (e.g. Xenomai) to render the scheduling algorithm in the kernel a real real-time one, but I'm not aware of the status of that patch right now.