This is probably a broad question but I'd like to know where concurrency is typically used for a mono user desktop application. How do you spot a case (at design stage, ideally) where concurrency issues might arise?
P.S: From OS theory, I'd say concurrency issues usually take place when a resource can't be shared (ex: printer). I'm still foggy on where this could take place on the programming level though.
There can be threading issues in Swing between the Event Dispatch thread and other logic. It's normally a bad idea to run long running code on the EDT since this means the user interface looks like it's locked when it's just waiting for code to run. The solution to this is to run long running code in a ProgressWorker which creates a new thread.
Here's where we can get problems. If both the worker and the EventDispatch thread are changing things at the same time there can be concurrency issues (imagine looping over a list while another thread modifies it). This isn't normally an issue however since good swing code will only modify Swing components from the Event Dispatch Thread anyway.
Imagine you are writing a collaborative text editor. You will have a GUI thread taking input from the user and a network thread receiving updates made by other users. These 2 threads will have to both concurrently access the objects which represent the state of the text that is being edited, and their accesses to that object will have to be serialized using mutexes or other synchronization primitives.
Generally speaking this is when a long running task needs to be executed that, if it were executed on the event dispatch thread would noticeably lock it up while it completed. So grabbing pages back from the internet, heavy processing, disk i/o and so on would all be better not in the event dispatch thread but as separate threads.
Out of scope slightly, but generally the best tool to deal with these situations is SwingWorker, which allows a task to run in a separate thread and notify swing of its progress and completion in a thread-safe manner.
to make things clearer, one visible manifestation might be when flickering issues arise like here. or you can imagine a picture displayer programmed in swing where large sized pictures are to be loaded and displayed. if not threaded properly on the swingworker, this might diminish the user experience as he waits for the image to load at the same time as the components are being set. so to answer your second qn-
How do you spot a case (at design stage, ideally) where concurrency issues might arise?
you can identify places where there are resource intensive operations occuring (e.g. image loading) and place these on the swingworker thread.
