30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
Performance on multi-core systems and application responsiveness can often be achieved with less risky / easier-to-debug / easier-to-test solutions such as asynchronous or event-driven design, multi-processing / pipelining (the Un*x way).
If you still need threaded execution in one process, always design your data flows first, implement a single-threaded version, then look at where adding threads would actually help, such as providing parallel computation or interfacing to a synchronous API in the background. Use well-tested threading libraries to help (such as built-in pooling in .NET CLR), isolate and synchronise threads through data flows, typically with queue objects, writing testable worker methods and exposing measurable data flow metrics (queue lengths) to diagnose problems..
Thanks Aditya, if you don't mind I'll add a couple of things to think about when considering the use of threads in any language:
Thank you for adding these points