Keep debugging with "difficulties"; it would be the best advice. Just debugging, with a single thread, also seemed difficult at first, right? But you used to it. Same thing with multi-threading debugging.
You should also understand that if you have problems with the design of multi-threading code, you won't be able to locate the using debugging. Same goes about testing. You design should be theoretically validated. One of the reasons for that is this: the code could have
race conditions, which means incorrect dependency on the order of execution. When you debug such code, you strongly delay one thread relative to another one, and the order of operations changes, so the code won't behave the same was as without the debugger. Please see:
http://en.wikipedia.org/wiki/Race_condition[
^].
Worse, due to race conditions, you can have the code which only seems to behave correctly, but will fail eventually (say, when the application is already deployed to the customer :-)). The failure can be as bad as it can possibly be, such as, for example, a
deadlock or something else.
At the same time, wide class of applications can be build based on simple well-known patterns of threading which never fail. This is all the matter of knowledge and experience.
—SA