Here's an updated architecture sketch of AudioMan:

(yep, hand drawn again)

I've been thinking a lot about multithreading AudioMan, and here's what I've come up with so far. Note the diagram is different from the old diagram -- it hasn't even been two weeks yet. That's why I don't put a lot of effort into making them look nice: they change too much. If you are lost reading this post, you might want to try reading the old post first -- it may help.

The major multithreaded situation I have right now is when someone wants to browse the collection while a long Include Directory operation is going on the background. My solution to this problem is to temporarily make the repository (dB in diagram, it can be thought of as a database) read-only while I'm updating the UI and then unlock it when I'm done.

Using the numbers in the diagram above, here's a typical scenario:

A1. Include Directory X
A2. Crawling directory X and its subdirectories
A3. Found a track, add it to the repository
A4. Mutator notifies the controller a track was added
A5. Controller notifies the models a track was added
A6. Models notify the UI a track was added; track appears in the view
(return to A2 and repeat an arbitrary number of times...)
B1. User wants a different view; UI asks the controller
B2. Controller locks the repository, making it read only; asks for updated tracks for models for the new view
(now that the repository is locked, the Include Directory operation blocks on A3 and stops)
B3. Controller checks the tracks to ensure they are up to date with their respective files and formatting is correct
B4. Controller makes new models from the tracks
B5. Controller passes the models to the UI; UI loads the new models asynchronously (with asyncExec())
B6. Controller unlocks the repository
(A3 is unblocked and Include Directory resumes)
B7. Controller gives the mutators tracks to update
etc...

A lot of this architecture already exists in AudioMan, I just haven't had a chance to talk about it yet. There are two potential problems that I don't have enough information about which could be issues:

1. When the Include Directory resumes and the controller gives its list of files to update to the mutators, will there be a "collision" of sorts since both threads are using the mutators? I don't think so. The mutators are singletons but they do not contain any instance specific information. They do not have state. So the threads can context switch using the same mutator singleton without any problems as far as I know ... but I am still unsure. I will have to look into this more.

2. After the controller unlocks the repository in B6, the mutators will resume and could notify the models of changes before the models are properly connected to the view and can notify it. This by itself seems to be OK since the models hold onto these updates, so when the UI is ready to load the models (with setInput()) they will be up to date.

However, there could be a short period of time during the connection process where the models have already been connected to the UI but aren't notifying it of changes yet. If that is the case, the view will miss updates. A solution could be to attach the view's model listener first and then load the model into the UI. Of course, this may give the view false updates just before the the new model is connected because it is listening prematurely. However, the view will be cleared when the new model is connected to it anyway and the model has those updates as well. So I believe everything will appear correct in the end.

Any comments? I realise this may be a lot to digest. If I didn't explain anything well enough please let me know.