Race conditions will be with us as long as people create software programs.
No best practices will completely guard you from race conditions, because correct use of best libraries and best practices still involves humans and a human cognitive error on all the stages, design, implementation, test, support.
We used the following principles:
First: We have learned that your best friend is a sophisticated dynamic analysis tool that is always on, analyzing every execution of your application. (Think of time and energy conservation. Why to waste the energy of software process execution?)
Second: Make your user to be your tester.
I.e. release the product with an agent that performs the analysis at run time. That will shorten the time to market, as you will have the assurance that any missed during the tests race condition will be analyzed in real time and you will know about it before the user will.
Third: Make the issues identified by the agent come to your console in real time.
Forth: Make your agent perform complete and detailed analysis in real time and completely automatically. Then you will never have to worry about programmer not making incorrect analysis, even if your programmer was lucky to recreate race condition (often a very difficult proposition). Microsoft's research shows that over 30% of analysis of (detected) race conditions (by humans) was done incorrectly.
Fifth: If the analysis is captured alone with the dynamic information of the system, you will never have to worry about being able to reproduce the issue.
Six: 100 agents are less expensive and more reliable that 100 human testers. So if your console receives aggregated results from 100 (or more) agents, your Time-To-Market component affected by your testing just got 100 (or more) times shorter.
And Seven: If the analysis by the agent is explained on the level of source code, (while the agent actually analyses bytecode and no source code is provided or available at the time of the analysis) your "Black Box Testers" become "White Box Testers" overnight.
PS: This is not just an opinion, but a personal experience afforded by using the tools built by TinkingSoftware.com
Disclaimer: I would not be able to provide such detail answer if I was not involved in building and using this tool, "Race Catcher", and this service, "ARM-CM", standing for Application Reliability Monitoring via Collaborating Machines.