Recently I've finished learning about multithreaded programming on single shared objects, but was curious about how different things would be in order to successfully program on multiple shared objects?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as not constructive by Jim G., Glenn Nelson, MichaelT, gnat, Martijn Pieters Mar 8 '13 at 8:42
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.
This is a very hot current research topic. The question of how to properly share data between multiple, concurrent, processing units, doesn't have obviously good answers yet.
Some of the issues that change and you should think about:
The difference is that usually when you have multiple shared objects, they live in some sort of collection (like a hash table, linked list, tree, or whatever). This requires some kind of pattern for how the locking will work.
The simplest solution is to have one lock for the collection. A thread can acquire the lock, find the object in the collection, work on that object, and then release the lock. This is very simple and for some cases is the best solution. But the big downside is that two threads can't work on two different objects in the same collection.
You can also have one lock for the collection itself and one lock for each object in the collection. You then acquire the collection lock, find the object you want, acquire the lock on that object, and then release the collection lock (assuming you aren't going to modify the collection itself). This allows other threads to search the collection and modify other objects in the collection while a thread is working on an object in the collection.
There are all kinds of other "in-between" approaches. But the basic concept is the same -- you still must ensure that a structure cannot be accessed by one thread while another thread is, or might be, modifying it.